As a visit to Damnoen Saduak Floating Market of Thailand will
confirm, time-to-market and distance-to-customer are distinct advantages in
business.
It is difficult to know which came first: the customers with their curiosity
and pocketbooks or the merchants with their bamboo and palm hats and colorful
produce, but they are certainly mutually drawn to one another. People do not
come here because the prices are cheaper but rather because the produce is
fresh, accessible and sold in a convenient and interesting way. In bygone days,
the vendors would paddle their boats on the waterways buying, selling and trading
fruits, vegetables and other goods all across Bangkok’s canal system. The canals were convenient, the boats
efficient and the coverage of the canals was pervasive across all of the city.
Where am I going with this?
Today’s mobile networks are pervasive, mobile apps are
interesting and they can get to customers first, right where they are.
When it comes time to build mobile apps that can reach
customers, time-to-market has more to do with the ability to develop mobile
apps that run on multiple device operating systems and integrate to back-end
business transaction systems in an efficient and agile manner. Distance-to-customer
is the advantage that mobile apps have because they reduce the transaction
distance between you and your customer to zero. Your ability to sell to
customers is no further than the palm of your customers’ hand.
But quite frankly time-to-market is often a disadvantage of mobile
apps because of the long lead times required to develop mobile apps using
native platform development tools. That’s why when we see a platform that
claims to marry the advantages of rapid development techniques, pre-built
integration solutions and a capability for cross-platform mobile smartphone and
tablet deployment, we have to pay close attention. Faster time-to-market for mobile apps requires a smarter application platform.
Most development
approaches fall prey to the time-quality-cost triangle and suggest that you can
choose only two of the three beneficial qualities: less time and more quality
or less time and less money or more quality and less money. The prevailing
wisdom suggests that you cannot have all three. But frankly this popular dilemma
is based on the preconceived notion that all approaches require a fixed effort.
What Magic Software initiated in the 1980s with the notion
of a rapid prototyping platform for creating business applications carries
forward today into some fairly slick and sophisticated technology that still
gets overlooked far too often by the mainstream computer programming community.
The benefits of an application platform can be found in the fact that it breaks
through the problem of fixed effort. Platforms have built-in solutions. They
allow for very rapid results by leveraging common application development
requirements in an underlying solution set or platform.
Daniel Coyle, author of The
Talent Code says: “Baby steps are the royal road to skill.” As I have said
before: “Regardless of whether you use agile or scrum project management
methodologies, early and frequent results are essential. Too many projects are
cancelled midstream simply because their progress is shrouded in mystery.” An
application platform gets you to those early victories and propels you to
frequent wins that will keep executive sponsors engaged to completion and asking
for more.
Native development suffers in comparison to Magic xpa
application platform development for a number of reasons. First. More tools are
needed. This is not opinion, this is fact. With native development you need a
server-side language and deployment methodology and a client-side language. Furthermore,
the client-side languages are different: Objective-C, J2ME, J2SE, etc. Because
of the extra effort required by these tools, more programmers are assigned to a
mobile app development project. While environmental complexity increases with native
mobile development, the Magic paradigm of platform based metadata development remains
constant: one tool for all requirements – server-side and multiple OS clients.
To understand the absolute significance of this, one needs
to consider the COCOMO II Model of software estimation perfected at the USC
Center for Software Engineering. (Go Trojans!) The COCOMO II model can be
simplified as follows:
Effort = (Team) x (Tools) × (Complexity)(Process)
As you increase the number of programming languages needed
(tools), effort increases. The concept is fairly simple. As you increase the
number of developers (team), effort increases. And as you increase the
functional requirements of the application to be delivered (Complexity), effort
increases. The relationship between these three components of effort is
factorial.
Those restaurants along the canals of the Damnoen Saduak
Floating Market want their vegetables really
fresh. For really fresh mobile apps, consider the Magic xpa Application
Platform.
