Abordamos nessa Edição o Tema de Desenvolvimento de Apps para Mobile com a Plataforma de Aplicações Magic xpa.
Você sabe que a mobilidade empresarial é o nome do jogo. Mas BYOD (Bring Your Own Device) e a consumerização de TI mudaram as regras.
Não só as empresas precisam fornecer aplicações móveis para múltiplos sistemas operacionais e formatos, mas também precisam desenvolver uma grande quantidade de aplicativos pois cada departamento compreende como eles podem usar o celular para desbloquear o valor do negócio. Para fornecer o valor máximo, esses aplicativos terão de se conectar a vários sistemas corporativos backend, ter a possibilidade de trabalhar desconectados e proporcionar alta performance, escalabilidade e segurança exigido pelas organizações empresariais.
2. Agenda
Magic Sem Segredos
• Desafio x Solução
• Magic em Ação
• Perguntas e Respostas
(Comentários do Blog)
http://mss.magicsoftware.com.br
3. Quem somos
Um fornecedor global de plataformas de desenvolvimento e
integração de aplicações
30
Com foco em
anos
Especialistas
em
Experiência
comprovada
Tecnologia e
Inovação
Necessidades de
Negócios
5. Como entrar e sobreviver nesse caos?
Multi-platform applications
Web/HTML5 App stores
What should I do?
Native
CRM
development
Javascript
User Interface
User experience
Performance
Hybrid Cloud-based Native
applications Smartphones
Legacy
5
Online/offline
security
Manufacturing Future proof
6. Conectar os sistemas corporativos é uma das
principais questões.
Sistemas de TI Corporativos
Cloud
DMZ
CRM
ERP
Legado
RH
1. Que dados ? Que Lógica ?
2. Complexo, Não Escalável, Não Seguro
6
Smartphones (BYOD, corporate)
Tablets (BYOD, corporate)
15. Plataforma Magic xpa para apps híbridos e
nativos
1. Lado Cliente + Lado Servidor + Integração
Integração
Modelo / Metadados
Plataforma de
Desenvolvimento, Execução e
Integração de Apps Mobile
Lado Cliente
Lado Servidor
2.
Teste, execução,
manutenção
16. Solução Magic de Mobilidade Corporativa
Magic xpa
Uma Abrangente
Plataforma de
Aplicações para
Desenvolvimento de
Soluções para
Web, SOA e
Desktop
Magic xpi
Plataforma de
Integração de
Sistemas e
Processos de
Negócios
Magic MDM
Uma Solução de
Gerenciamento de
Dispositivos Móveis
(Mobile Device
Management) para
segurança, monitora
mento e controle
centralizado e
suporte.
Magic Mobility
Professional
Services
Serviços para ISV's
(Parceiros) e
Empresas (Clientes
Finais)
18. Obrigado e até o próximo
http://mss.magicsoftware.com.br
Notas do Editor
Today, you can hear many buzzwords around mobile enterprise application: technologies like HTML5, Javascript, native, hybrid, cloud but also mobile capabilities, user interface…there are many philosophical debates that makes decision-makers and IT managers a bit lost or at least very cautious in their strategy or later at the implementation phase.The changing environment is mainly driven by 2 main trends: Consumerization of IT and OS fragmentation
For enterprise mobility, the most costly and most technically challenging issue for enterprises is not the User Interface or client-side application (although it has his own problems –we will get back to it), but the value (data, process, application) that resides into Enterprise IT systems and that needs to be unlocked to mobile in an enterprise grade mode (scalable, performance, security).The connection to enterprise IT systems is most often, under-estimated and bottleneck in a mobile project compared to client-side or User Interface development. It usually represents a high effort and cost in the overall project because it often requires expensive, specialized resources both on the technical and on business side.. In a recent report, MGI Research assessed it as a 70 % add-on on the mobile project cost.Main issues here are what data, what process to mobilize, how to combine diverse data types and data, how to streamline a end-to-end process to a mobile user (CRM+ERP, HR+real-time,…), social + internal processes….
A seamless and intuitiveUser experience is also a key requirement but fragmentation is a barrier that needs to be overcome.The WW smartphone OS market is highly fragmented and has dramatically changed over the past few years. RIM market share has plunged while Android for instance has plummeted.Even fragmentation can exist within the same operating system and this is the main problem of Android.Android: versions: 2.1 to 4.2 (10 different versions)4 different sizes (small, normal, large, extra large). For each one, you have 4 different densities (low, medium, high, extra high)This platform fragmentation in term of OS, form factors, processing…is a key issue when succeeding in entreprise mobile app projects, and obviously knowing exactly where mobile enterprise apps will be deployed on is essential.The differences between OS capabilities and UI philosophies, form factors and processing power has a huge impact on the User Experience.But before deployment, you have the development phase with technologies, languages and tools and here too, multiplicity but also proprietary and non-standard technologies and languages make everything complex.
I would like to give an example of developing a native application with a native development language.A typical project would start with a client side development with one stream per targeted platform, then multiple server-side development streams using for example PHP, AJAX or Ruby.Then you would add as many integration development streams as required for point-to-point integration.Obviously you would need to develop also the communication layers and test, deploy and maintain all these.The whole process is quite heavy, risky in term of quality and not adapted to fast time-to-market environment.
I would like to give an example of developing a native application with a native development language.A typical project would start with a client side development with one stream per targeted platform, then multiple server-side development streams using for example PHP, AJAX or Ruby.Then you would add as many integration development streams as required for point-to-point integration.Obviously you would need to develop also the communication layers and test, deploy and maintain all these.The whole process is quite heavy, risky in term of quality and not adapted to fast time-to-market environment.
I would like to give an example of developing a native application with a native development language.A typical project would start with a client side development with one stream per targeted platform, then multiple server-side development streams using for example PHP, AJAX or Ruby.Then you would add as many integration development streams as required for point-to-point integration.Obviously you would need to develop also the communication layers and test, deploy and maintain all these.The whole process is quite heavy, risky in term of quality and not adapted to fast time-to-market environment.
Let’s take now a web or hybrid application developed with web technologies.A typical project would also start with a client side development using HTML5 for example, with this time one development stream for all the platforms , then multiple server-side development streams for server-side logic.Then you would add as many integration development streams as required for point-to-point integration.In the same way, you would need to test, deploy and maintain all these.The whole process is less heavy and risky but still not optimized .
Let’s take now a web or hybrid application developed with web technologies.A typical project would also start with a client side development using HTML5 for example, with this time one development stream for all the platforms , then multiple server-side development streams for server-side logic.Then you would add as many integration development streams as required for point-to-point integration.In the same way, you would need to test, deploy and maintain all these.The whole process is less heavy and risky but still not optimized .
Let’s take now a web or hybrid application developed with web technologies.A typical project would also start with a client side development using HTML5 for example, with this time one development stream for all the platforms , then multiple server-side development streams for server-side logic.Then you would add as many integration development streams as required for point-to-point integration.In the same way, you would need to test, deploy and maintain all these.The whole process is less heavy and risky but still not optimized .
Finally, last example is developing hybrid or native applications using an end-to-end development platform covering client-side, server-side and integration development.You would have only one development stream this time and the whole process here would be optimized for best quality, time-to-market and high flexibility.