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.

For the last 3 weeks I've shared some of my thoughts related to Andy Grove's book, Only the Paranoid Survive,. In this final post in the series, I'd like to talk about the idea of continuously challenging your own opinion and changing course mid-stream if required.

The first thing I would say is that I do not think that Grove is suggesting that we easily change course based on any new data point that comes to attention. However, it is critical that alongside the other principles of gathering opinions at all levels of an organization, and demanding vigorous debate, that organizations do not let their decision history become "law" that requires a Supreme Court ruling to overturn. Instead, if new information comes to light that is vigorously debated and results in a desire to change the group's trajectory, the leadership culture shouldn't protect previous ideas even if it requires personal sacrifice.

For example, an executive who was closely aligned with Intel's memory business may have had personal attachment to the decision to exit from that line of business. Seeing beyond one's personal history in an organization is extremely challenging. It requires a culture that shows people that it will reward them for helping bring the right decision forward, even if it means it would put an end to something that was their core function.

Among other reasons, Grove was able to do this during his time at Intel by creating an environment that harvested opinions from all layers of the enterprise, funneled them into meaningful debate, and crafted a decision making process that embraced continual self-evaluation. 

Over the past 2 weeks I've written about topics from Andy Grove's classic business book, Only the Paranoid Survive,. This week I'll expand into the idea of decision making with imperfect or incomplete information.

Grove talks about the idea of driving forward with decisions that make sense based on the information that is there, rather than the information that isn't. Discovery of new information may change the fundamentals behind a decision. However, waiting for all of the information to be available can be the poorer choice if it means a stagnant culture, slow response to customer or market demands, or letting competitors get ahead of you.

The interesting thing to me is that this idea seems to tie in perfectly to the idea of organizations applying "Learn By Doing" which I wrote about here. This is particularly true when you combine the idea with what Grove describes as the need to continuously challenge your own opinion, which I'll write on next week. It is much easier to pull the trigger on a decision that has imperfect data supporting it, if the culture exists to change course if and when needed. On that note, it is critical to understand that you can't implement Grove's ideas piecemeal. If you implemented just this part without the other principles of continuously challenging opinions, seeking ideas from all levels, and demanding debate, you are setting yourself up for potential catastrophe. Under Grove, Intel was able to execute their decision making process using these concepts because they were also able to rapidly adapt if new information arose that caused them to challenge their prior opinion.

Next week: Challenging your opinion continuously and changing course mid-stream...

Last week, I started to discuss some of the leadership principles Andy Grove speaks to in his classic business book, Only the Paranoid Survive. Last week I wrote about the idea of seeking opinions from all levels of an organization. This week I'll continue by focusing on the theme of encouraging vigorous debate.

One of the most dangerous types of decisions is the one that is made when people around the table aren't saying what they really think. Andy Grove highlights this by talking about how Intel demanded vigorous debate throughout all decision making meetings. In comparison, I've seen many board or committee meetings that are consensus focused and create momentum around a decision before real debate occurs. People sometimes think they are debating an issue simply because someone decided to briefly and often meekly play "Devil's Advocate" and say a few things about what could go wrong. But, did you really vigorously question the underlying assumptions behind your ideas. Did you really demand everyone think through both sides of the equation? Grove says that we should demand vigorous debate at all costs. The related subject of getting people to share their opinions is a prerequisite to getting team members to truly debate a subject. It is important for leaders to show that they want to discuss an idea. When a "key person" in a room throws an idea on the table, it shouldn't end discussion around other ideas.

This is tough. In my own experience, the leaders of a group have to constantly reinforce that they expect the team to come up with competing ideas and be open about knocking things down that don't make sense, regardless of who put the idea out there to begin with. I am constantly looking for new ways to achieve the type of success that Grove talks about in this area. In my experience, the only way to make this type of thing happen is to ensure there is an environment that strongly encourages and rewards these activities.

Next week: Don't hold back decisions due to a lack of information

I am fortunate to have studied at Cal Poly, San Luis Obispo. Cal Poly is a great university and one of its defining characteristics is a motto called “Learn by Doing”. The idea is to ensure that students are engaged in the real world trying out ideas. Everything that is done across all disciplines at the university in some way relates to this philosophy. I found it to be very compelling while studying, and I’ve since found Learn By Doing to be even more powerful in the business world.

One of the things I often hear from executives is that they feel they can’t change a process due to risk. It is true that changing processes always carries risk, and in some cases the risks are intolerable without a huge amount of due diligence. An often overlooked concept is the idea of rapid prototyping. In the software world, rapid prototyping is widely used. In many business processes, it is possible to carve out a small sample set that would be statistically relevant, and try out a new process in a limited way before rolling it out on a widespread basis. Many executives do not consider this option and focus purely on information they can gather on “Best Practices” from other organizations. There are certainly lessons to be learned from “Best Practices” and we  actively encourage our clients to adopt them in many cases. But, by definition if you only follow “Best Practices” you’ll end up squarely placed in the wide band of “Average”. If you want to really drive innovation, you have to try new things before they are adopted as “Best Practices” and I’ve found that the Cal Poly motto of Learn By Doing can be applied quite effectively to try out different ideas.

Since I run a company that provides enterprise software technology, the subject of this blog post may seem odd. Certainly, enterprise business applications have provided organizations with tremendous value over many years. While that is true, the question I am asking has more to do with the long term lifecycle of a business application. Markets and customer demands change over time. Therefore, businesses must change over time. Processes must change over time. People must change over time. And, to support all of this, business applications must change over time. I have heard countless times from executives that the reason they perform a process a certain way is because their technology forces them to do it in that manner. In some instances, a system imposed process can be a good thing, helping a company adopt best practices that are known to be assets in other organizations. In some cases, such system-mandated processes are neutral in their impact. But, in many cases, being locked into an antiquated method of doing business can be devastating.

The rate of change in business today is seemingly greater than at any point in time in recent memory. Businesses and consumers demand nearly instant adjustment to evolving preferences. The winners in many markets are those companies that are most nimble. Most business applications promote some efficiency gains when they are initially built. Over a period of time, however, they might be making a very bad process very efficient. Inflexible technology is often the culprit but the issue also has to do with organizational structure and culture. Many groups provide their internal IT departments with complete control over all aspects of their applications. In order to change any system process, IT has to bless the idea and then figure out a way to implement it. There are many other examples of similar challenges in other departments too. A typical result is that the business needs in support of innovation are often not met. There are many dimensions to this discussion and I’m not suggesting that IT should let business owners run rampant in changing anything they want at will. The point I’m making is that technology and business have to go hand in hand, both supporting rapid innovation and the idea of experiential learning.

I frequently hear amazing stories of innovation in the technology business. There are many remarkable stories in other fields such as medicine, energy, agriculture, and countless others. In most organizations, continuously seeking out game changing innovations is identified an important goal. Hopefully, the environment that you are in lends itself to the type of creativity that is necessary to drive innovative ideas. When you have ideas percolate up, one of the questions that needs to be applied is that of scalability. That is, can the innovative product, service or process scale up and be replicated on a wide spread basis.

For example, perhaps an individual on your team suggests a process change that could reduce customer wait times by 30%. You get excited because this could be a powerful improvement to your service. Perhaps, however, the suggestion is dependent upon a skill, talent or other capability that is only evident in a small percentage of the people who would be in charge of executing it. Repeatability is required to achieve scale in any innovation and it is important to consider this factor with any new idea.

When evaluating a business opportunity it is important to remember to ask the question “Why isn’t anyone else doing this?” Perhaps your idea is so innovative that nobody has thought of it. Or perhaps the timing of your idea is now feasible due to an advancement in technology, business practices, or consumer tastes. Perhaps.

But, in case those factors aren’t present, don’t forget to ask this question of yourself and others when considering new businesses, offerings, processes, or other forms of innovation. Openly and honestly debate the answer to this question including getting thoughts from trusted and impartial observers who are familiar with your industry. If you skip this step you might be ignoring a landmine that could have already snared other would-be innovators who have tried to blaze the same trail. At the same time, don't be discouraged by naysayers - just make sure you turn over this rock so you aren't surprised.

I recently had the pleasure of speaking to a group of undergraduate and MBA business students at the International Career Conference held at Cal Poly in San Luis Obispo, California. I was honored to have been invited to keynote the conference and also participated in a panel discussion later in the day. During my keynote I spoke about common themes that I’ve seen in growing Aptify over the past 16 years and specifically talked about innovation. One of the main points I made to the group was that you can’t innovate with perfect data, and in many cases little to no data is available at all. Traditional methods in market research require validation of a wide variety of input factors before making a decision to pursue an idea or opportunity. While such methods are quite valuable, they have to be adaptable to the environment you are in.

True innovation, by definition, means you are doing something that is new. If what you are considering has been done before you’ll probably be able to find a great deal of information. If, however, you are embarking on a new process, method, or bringing a truly unique product or service to market, you may not find directly relevant data. You have to be willing to make a logical leap from the intended benefits/value proposition of your idea to estimating if results will be successful. I recently read a great column in Business Week by Roger Martin and Jennifer Riel that speaks to the same general theme.

What experiences have you had fostering innovation in your organization and how do my observations compare to your own history?