{"id":6433,"date":"2013-07-16T09:30:23","date_gmt":"2013-07-16T14:30:23","guid":{"rendered":"http:\/\/www.mrc-productivity.com\/blog\/?p=6433"},"modified":"2022-11-22T10:57:00","modified_gmt":"2022-11-22T16:57:00","slug":"6-tips-for-building-applications-that-last","status":"publish","type":"post","link":"https:\/\/www.mrc-productivity.com\/blog\/2013\/07\/6-tips-for-building-applications-that-last\/","title":{"rendered":"6 tips for building applications that last"},"content":{"rendered":"

\"Education\"<\/a>Let me make a wild assumption: You probably don\u2019t want to replace your business applications every few years. You\u2019d like to build applications that last. You want to build applications that grow with your company and adapt to changing technology.<\/p>\n

The big problem<\/strong>: Technology is evolving faster than ever, which makes business application development even more challenging. If built incorrectly, a modern application today might be outdated in just a few short years. Obviously, businesses can\u2019t afford to replace their applications every few years. <\/p>\n

How can you build applications that remain relevant for years to come? How can you build applications that scale with your company and adapt to changing tech trends?<\/p>\n

To help you answer those questions, I\u2019ve compiled a short list of tips that will help you build applications that last. Now, I\u2019m keeping this relatively high-level. We could write pages and pages on how to implement each point below. Rather than get into all of the details, here are the key aspects to consider when building applications for the future.<\/a><\/p>\n

1. Start with the database<\/h3>\n

\"data_blue\"These days, implementing a simple database and building applications over that database is quite simple with the right software. The problem is–this means anyone can set up a database without paying much thought to its structure. If that application grows, the poorly-designed database will ultimately hold it back.<\/p>\n

\n\u201cThe most important factor is a good database design,\u201d says Luke Chung, President and Founder of FMS, Inc.<\/span><\/a> \u201cA design that scales over time as new data is added. Simply, \u2018records are free, fields are expensive\u2019. A design that requires changing table designs does not scale properly. Many software developers are not database experts and don’t realize the impact of time. Assuming the database is well designed, any technology that addresses the needs of the organization can be used.\u201d\n<\/p><\/blockquote>\n

2. Architecture, architecture, architecture (Did I mention architecture?)<\/h3>\n

If you feel like I talk about application architecture a lot…you\u2019re right. But, I do it for good reason. The importance of application architecture<\/span><\/a> cannot be overstated. It doesn\u2019t matter which technology you build your application around–you need a well-architected application if you expect it to adapt and scale with your company. <\/p>\n

\nTyler Wassell, Software Development Manager at mrc<\/span><\/a>, explains the importance of application architecture: “When IT leaders look at their portfolio of business applications, they should be asking a few important questions: Can we move these applications to the cloud if necessary? Are they secure? Can they be accessed from mobile devices? Can we cost effectively maintain, modify, and customize them as our business needs changes? Do they scale? If the answer to any of these question is “no”, attention should be given to the underlying software architecture.”\n<\/p><\/blockquote>\n

Now, what if you aren\u2019t experienced with application architecture? My advice: Find someone who is, or find a development platform\/tool that handles the application architecture for you. The point is this: You cannot afford to skimp on application architecture. Spending time on software architecture now can reduce failures in the future. Whatever money you might save rushing through the architecture planning phase, you\u2019ll lose many times over when you\u2019re stuck rebuilding your application a few years down the road.<\/p>\n

2a. Separate your architecture<\/strong><\/p>\n

Taking the architecture point one step further, K. Alan Robbins, CEO of Moose WorldWide Digital<\/span><\/a>, explains that one key to building applications that last is \u201cTiered architecture, where the database, business logic, and presentation are loosely coupled. It costs a little more to build apps this way, but if done properly it enables the presentation layer to be changed without throwing out the entire application. For example, a business functional web site can be repurposed into a tablet application.\u201d<\/p><\/blockquote>\n

\"nTierMobile\"<\/a>I couldn\u2019t agree more. Separating your application architecture into separate tiers dramatically improves its ability to adapt over time. How? Robbins touched on it briefly, but here\u2019s another example: Suppose your applications are beginning to look outdated. With a tiered architecture approach, you can simply update the presentation layer with a completely new look and feel, without even touching the underlying database and business logic. Without the tiered approach, you\u2019re stuck rebuilding the entire application.<\/p>\n

3. Build for a platform that will last (Hint: It\u2019s the web)<\/h3>\n

Can you say with certainty which platforms will exist in 10 years? I can\u2019t. Maybe Windows will lose market-share. Maybe the popular mobile platforms (Android, iOS, Windows) will be replaced with different platforms. Who knows?<\/p>\n

When I really think about it, there\u2019s only one platform that I\u2019m 100% sure will exist in 10 years: The web. <\/p>\n

If you want applications that last, don\u2019t tie them to a single platform. If you\u2019re building applications for exclusive use on a single desktop or mobile platform, you put yourself at risk. What happens if that platform disappears, or a new popular platform emerges? The answer: Build web applications. The web is the only platform that works across any device and with any operating system…both now and in the future.<\/p>\n

4. Build with an established language<\/h3>\n
\n\"small_4443886636\"<\/p>\n

photo credit: nyuhuhuu via photopin<\/a> cc<\/a><\/i><\/div>\n

Look, I get it. Developers love trying new technology. They love experimenting with new programming languages, frameworks, libraries, etc… When something new comes out, they want to try it. Frankly, I think that\u2019s a great quality.<\/p>\n

However, it becomes an issue when you start building business applications using a newer language that hasn\u2019t quite taken off yet. What happens if that language never takes off? Then, you\u2019re stuck maintaining an application built using a language with very little community support. What if it doesn\u2019t work with future technologies? What if the language is abandoned due to poor adoption? While experimenting with new languages is fine, stick with established languages when building your business applications.<\/p>\n

5. Avoid proprietary software\/applications (use open source)<\/h3>\n

\u201cWhen companies build proprietary applications they not only commit to high initial development costs, but they commit large amounts of resources to supporting and maintaining the application in the future,\u201d says Gabriel Mays, Owner of Just Add Content, LLC<\/span><\/a>. \u201cIf they don’t, it stagnates. On the other hand, open source applications are built, maintained, and supported by thousands of developers on a continual basis. Though some customization may be required, the bulk of the work is already done. The key is finding an existing open source framework or platform that fits the problem.\u201d<\/p><\/blockquote>\n

I\u2019d like to take that thought one step further: Avoid any path that ties you to a single vendor. For instance, some companies opt for development tools that create proprietary applications, which cannot be maintained outside of the software. This limits their future options, and ties their success to the success of the tool vendor. If you do choose the development platform\/tool route, opt for a solution built on an open foundation that lets you maintain your apps outside of the software.<\/p>\n

6. Build in flexibility<\/h3>\n

Let\u2019s face it: You can\u2019t possibly predict how technology will evolve, or which new capabilities your company will need over the next few years. However, with proper planning, you can leave the door open for new features down the road. <\/p>\n

\u201cMost software apps become Frankensites\/Frankenapps because they get so many tools and functions added to them down the road that their appearance and usability suffers dramatically,\u201d explains Jeff Kear, Owner of My Wedding Workbook, LLC<\/span><\/a>. \u201cWhen you are first scoping out your application, try to brainstorm all the potential uses that the software may have in the next 5-7 years. You probably won’t add many of these tools upfront, but if you have figured out a potential home for them in the application and built the framework so you can somewhat easily integrate them after the fact, then you won’t be kicking yourself down the road.\u201d<\/p><\/blockquote>\n

Wrap up<\/h3>\n

With technology evolving at break-neck speeds, building applications that last is more difficult than ever. How can you build applications that scale with your company and adapt to change? While you can\u2019t truly plan for everything the future might bring, the tips laid out above will set you well on your way to building applications that last.<\/p>\n

What do you think? Did I miss anything? If so, I\u2019d love to hear your thoughts in comments.<\/p>\n","protected":false},"excerpt":{"rendered":"

Let me make a wild assumption: You probably don\u2019t want to replace your business applications every few years. You\u2019d like to build applications that last. You want to build applications that grow with your company and adapt to changing technology. The big problem: Technology is evolving faster than ever, which makes business application development even …<\/p>\n

6 tips for building applications that last<\/span> Read More »<\/a><\/p>\n","protected":false},"author":4,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"default","ast-global-header-display":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","slim_seo":{"title":"6 tips for building applications that last - mrc's Cup of Joe Blog","description":"Let me make a wild assumption: You probably don\u2019t want to replace your business applications every few years. You\u2019d like to build applications that last. You wa"},"footnotes":""},"categories":[8],"tags":[13,36,15],"class_list":["post-6433","post","type-post","status-publish","format-standard","hentry","category-education","tag-application-development","tag-web-applications","tag-web-development"],"_links":{"self":[{"href":"https:\/\/www.mrc-productivity.com\/blog\/wp-json\/wp\/v2\/posts\/6433","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.mrc-productivity.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.mrc-productivity.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.mrc-productivity.com\/blog\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/www.mrc-productivity.com\/blog\/wp-json\/wp\/v2\/comments?post=6433"}],"version-history":[{"count":38,"href":"https:\/\/www.mrc-productivity.com\/blog\/wp-json\/wp\/v2\/posts\/6433\/revisions"}],"predecessor-version":[{"id":13852,"href":"https:\/\/www.mrc-productivity.com\/blog\/wp-json\/wp\/v2\/posts\/6433\/revisions\/13852"}],"wp:attachment":[{"href":"https:\/\/www.mrc-productivity.com\/blog\/wp-json\/wp\/v2\/media?parent=6433"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.mrc-productivity.com\/blog\/wp-json\/wp\/v2\/categories?post=6433"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.mrc-productivity.com\/blog\/wp-json\/wp\/v2\/tags?post=6433"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}