Aptify's CEO Blog

Code generators have been around for a long time. They have provided a significant productivity benefit to a great many developers. They speed up initial development in many categories of applications. They enable less experienced developers to build applications they couldn’t otherwise build. They sometimes can even target multiple platforms simultaneously. So, why shouldn’t they be used to build business applications? Read on to see why we think a development and run-time meta-data driven model is better for building dynamic business applications.

The fundamental challenge with Code Generators is that their goal is to generate code, not create usable business applications. Generating code creates several challenges:

• Code generators usually generate a great deal of code. The code is often complex and is hard for many developers to fully understand. The initial productivity boost can be compelling but unless the developer is quite familiar with the generation model, modifying the generated code is often quite a challenge.
• Code generators require developers for everything. Developers should be empowered to focus on what they really want to do anyway – work on the interesting and more complex challenges. Code generators that generate mountains of code and require code regenerations whenever application changes are needed require a developer to carefully manage all of that code, compile the code in a tool like Visual Studio, deploy the code to a stage/test and finally production environment. These steps should all be possible without a highly skilled developer doing them.
• Code generators bind people to a platform. The generated code that is platform specific must be modified by the developer in many instances and that in turn results in a challenge in porting code forward. For example, if you used a code gen tool to build a WinForms application and then decided to move your application to ASP.NET or Silverlight, you would have to extract your modifications from the code generator manually, migrate them, port them to the new environment, and then go forward retesting, etc.
• Regeneration limits what you can modify .In most tools, if you want to be able to regenerate an app after defining some changes, you have to be very careful about where you modify the generated code. Each code generator has a different scheme for providing areas to modify and some are certainly better than others. The fundamental issue though is that this approach can create a lot of complexity and limitation, coupled with risk that developers in a team setting will not universally follow the same standards creating situations where custom code is wiped out when the app is regenerated.
• Business Analysts and Power Users can’t participate. These days, many non-developers want to get involved in the process of creating business applications. This is most true in departmental workflow and line of business apps. For enterprise apps it is less common but a growing trend. Code generators are by definition developer centric tools. In order to empower a business user to get meaningfully involved in defining an application a code generator tool is a non-starter.

Dynamic Business Application Meta Data Driven Model

So, if Code Generation is less than optimal for business application development, what is better? Our view is that using a graphical, meta-data model that doesn’t generate code to define an app and is executed directly by a run-time meta-data engine is more productive and cost effective. The idea is for that meta-data to be open, easily extensible, and portable. The run-times can then support a variety of normally incompatible environments such as Windows and Web with the same application. The meta-data environment can go from simple to complex. For business users trying to define a simple or medium complexity app, they can do everything they want with graphical tools. If no complex rules or workflows are required, the business user can directly promote an app for testing and deployment without any coding, compiling, or manual deployment work. If a developer does need to get involved for more complex apps, define the code in a highly componentized and granular way that plugs in to the rest of the environment. Developers then get the best of breed development capabilities and language of choice within Visual Studio .NET. Their output is a portable extension to the meta-data that then is consumed by the run-time environment. The end-result is that the run-time framework can actually be modified in nearly any way imaginable, but it is done with plug-ins and run-time object consumption and aggregation rather than through code generation. End result: developers can focus their energy on building world-class software and business users can contribute meaningfully to complex apps and control a great deal more in simple to medium complexity apps. Even more importantly, the long term total cost of ownership is much lower since the meta-data is portable and will migrate from one major technology platform to another over time.

I'm excited to be co-presenting with Don Dea, Co-Founder of Fusion Productions, this Friday. We will be speaking on this topic: Integrating Social Media and Association Management Systems. Please join us from 2 PM to 3:15 PM at the ASAE Tech Show in Washington DC.

If a business application has inadequate security, it can wreak havoc on an organization. There have been plenty of discussions on the importance of tight security, particularly in the last year or so. While security must be tight in modern business applications, it is important that it fits in a way that eliminates or minimizes any impact on productivity. Many applications have wild pendulum swings from being far too open to being far too closed. Additionally, security is something that takes care and feeding over time since roles changes, users come and go, and the needs of an organization and its business processes change. Last, but certainly not least, security needs to be implemented in a unified model through all layers of the software. That is, the security in the user interface, business logic and database must all match, and must stay in sync over time. This is in fact one of the greatest administrative headaches that face administrators and application developers in many development shops.

Modern systems need to have a unified model with a single point of administration. This means that a system administrator can make changes to security in a single place, easily, and these changes automatically have impact on all layers of the software infrastructure from the database through the user experience. Many development shops ignore this approach as it does normally(see note) take extra time to invest in this level of security infrastructure. However, if you don't have a unified security model in place, the long term total cost of ownership will be much higher. Even incremental changes will have to be managed in multiple places and typically by different people (e.g. DBA/Sys Admin/Developers for different layers). In addition to the higher long term cost, the lack of a truly unified security architecture will likely increase security vulnerabilities and create quality problems. This is a great example in application development where a bit of additional infrastructure on the front end will provide for big usability benefits and cost savings over time.

Note: While the importance of this security model applies to all business applications in any environment, our Aptify RAD Platform automates this entire process and actually reduces the amount of time it takes to establish a unified security model in any business application.

Publishing Technology is the largest software provider to the publishing industry. PT selected Aptify RAD to form the foundation of their new generation of business applications.

Click here to learn how Publishing Technology benefited from Aptify RAD, our Application Lifecycle Platform.

A large percentage of web sites these days are driven by database content. As the impact of dynamic content continues to increase, it is important to have a high-availability strategy for your web site. A good first step to improving availability of your dynamic site is to use a replicated database server rather than connecting your production web site directly to a production database. This is second nature to some organizations that have been deploying web sites this way for years. For many groups, however, it is not something they have yet deployed. Setting up a replicated database server will bring several benefits to your organization. First, it eliminates the dependency on the network link between your web site (assuming it is hosted) and your production database. The model establishes redundancy as well since the production web server will not be directly accessed. This also leads to an improved security level as you can choose to replicate a sub-set of data to the replicated database server. Last, but certainly not least, the replicated server will take on the load from web requests and reduce load on your production database which should improve performance. If you haven't considered deploying a replicated database for your web site, consider the benefits of such a strategy in 2009.

Most organizations work on performance tuning in depth during an initial software implementation. After a go-live, however, it is fairly common to see performance tuning fall off the radar. The issue with this is that the database and related components are constantly evolving and require review on a recurring basis. We recommend to our clients to conduct a performance tuning review at least quarterly during the first year of use of our product and at least semi-annually thereafter. Some organizations can get away with less frequent performance tuning efforts and some need to evaluate their environment more often. The key thing to remember is that you have to build a plan to review performance on a recurring basis to make sure that system performance stays steady, or preferably improves. If you don’t, it is likely that performance will slowly degrade over time as the performance tuning that was done earlier is no longer optimal.

This is a key issue for all of your enterprise database software applications. The good news is that the incremental tuning exercises are typically not very time consuming once you establish a baseline. We recommend that people put this on their calendar along with other scheduled reviews such as a recurring security review and disaster recovery plan review.

The ability for a software application to be modified is now viewed as a critical requirement for most organizations. This is largely due to the dynamic environment we face where response times must constantly shrink while quality and innovation move forward rapidly. These days, most software companies state that they are flexible and have “toolkits” available to modify their applications. We see the evolution of the industry in this direction as being a very good thing for the market.

However, it is also important in such an environment where most vendors claim such flexibility to differentiate between a toolkit and a true platform. For well over a decade, Aptify has provided what we call the Application Lifecycle Platform, which is a comprehensive solution for developing, deploying and maintaining(including upgrading) enterprise business applications. We at Aptify use our own Application Lifecycle Platform for 100% of the development of business applications. In contrast, a toolkit is a set of separate tools that is used only by a customer to change a vendor’s application. The vendor doesn’t typically use such a toolkit to actually build the base applications. The distinction is an important one – if you and the vendor use different tools, you will always have a limitation to what you can do.

In the Aptify world, there is no such difference, the platform we provide our clients is the same one we use to build the applications to begin with. Our customers leverage this platform day in and day out to build not only extensions to our apps, but to create entirely new business applications. Underscoring the power and flexibility of our technology, Aptify’s Application Lifecycle Platform is being used by a major independent software vendor to produce a complete ERP suite for the publishing vertical.

When you compare software solutions, if flexibility is important to you, make sure you ask this key question of each vendor: Is the toolkit/platform something that you internally use to build 100% of the proposed solution? If the answer is not an unqualified yes, consider carefully the limitations before moving ahead.