Aptify RAD Blog

• Microsoft's Silverlight Strategy

  November 05, 2010

  Many of you have read recent blogs and articles questioning Microsoft’s commitment to Silverlight following statements made by Bob Muglia last week.  We’ve been following this closely and have been in touch with our contacts at Microsoft.  It’s clear that Muglia’s comments were taken out of context, and he has since posted a blog clarifying Microsoft’s strategy that Silverlight continues to be a strategic platform for rich line of business applications delivered over the web. 

  Muglia’s blog post is available here: 

  http://team.silverlight.net/announcement/pdc-and-silverlight/

  We still believe that Silverlight is the best rich internet application (RIA) technology available for delivering highly functional applications now and for the foreseeable future, and we remain committed to our Silverlight strategy.  In addition, we are closely following HTML 5 and we will support it when it becomes a suitable and compelling platform for Aptify and our customers.

  
  

  
  

  
  

  
  

  by Mark Patterson Vice President, R & D

• Build Dynamic Business Applications instead of just Generating Code

  August 09, 2010

  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.

  by Amith Nagarajan

• Business Application Security - Unification is Key

  June 10, 2010

  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.

  by Amith Nagarajan

• Application Vendors Should Focus on Business Functionality

  June 04, 2010

  A few weeks ago, I wrote about the difficulties many organizations face when they attempt to strike a balance between keeping up to date on Microsoft technologies and optimizing their internal operations. Many businesses and member based organizations are turning to packaged software products rather than taking responsibility for building business applications from the ground up. A similar case can be made for commercial software vendors who believe that their main competitive advantage resides in business application expertise rather than lower level technical innovations.

  Domain Expertise as a Competitive Edge

  While software companies that focus on building operating systems, programming languages, database software, and application frameworks must have competitive advantages in lower level programming, the same is not necessarily true for firms delivering specialized business application functionality to customers. Well designed business application software, particularly for specialized vertical markets, depends on deep business domain expertise of those who are developing the system.

  Domain expertise in a particular industry takes a significant amount of time to acquire and application designers need to have the necessary level of business acumen required to efficiently translate requirements into software. This is a skill set that is often far different from what a lower level programmer would need to build developer tools or application frameworks. Even if a software company focusing on business application functionality has programmers with significant low level programming skills, it may still make sense to use a well designed business application framework for the same reasons that a company might want to avoid building in-house software from the ground up.

  Ultimately, commercial software company executives need to ask themselves what motivates their customers to select their software over competing products. If the answer involves providing more efficient business productivity through extensive domain expertise, it may make more sense to invest heavily to improve business functionality rather than focusing on lower level layers of the software stack.

  Risks Require Management

  The strategy of focusing on business application functionality rather than lower level technology is not without risk. If a commercial software firm focuses only on business functionality while relying on partners or other vendors to supply lower level technologies, there is always a risk of falling behind strategically on big picture issues.

  Managers can minimize this risk by associating with partners who have a proven record of innovation and by having enough expertise within the company to question the partner when it comes to technologies and big picture issues. Customers require complete solutions and rely on business application vendors to deliver turnkey systems. While controlling the entire software stack may provide a certain theoretical level of control, a software firm with limited resources will likely find it more effective to focus on business application functionality built on an application framework developed by a trusted and proven partner.

  Aptify

  Aptify's own case is not different from that which is being described above. It so happens that our company has two distinct lines of business operations: one focused on Aptify RAD, our core platform technology, and the other is a domain-specific vertical market solution for Associations, Membership, Events, and similar organizations. Our case is fairly unique since we have two successful and independent lines of business. In fact, other commercial software companies are choosing Aptify RAD as a business applications platform to build commercial software upon. At the same time, we have a large number of resources directly in the business of providing a particular vertical market with leading edge domain-specific functionality. To make this work internally, our development group focused on the AMS (Association/Membership) market, must focus purely on application functionality and business processes in the vertical and not get into the lower level development functions described above.

  by Amith Nagarajan