Creating Stunning Enterprise Apps for Both Web and Mobile

Editor's Notes

• #3: Technology has changed the business landscape – it has displaced incumbents, it has led to entirely new industries, it has completely changed industries. Technology has changed our lifestyles – think about digital natives and how their lives are different from non-digital natives, think about how your interactions have changed with the advent of social media, etc.
• #4: It’s clear that technology can be a differentiator - companies that leverage tech win, or they are major market movers, influencers. For example… Uber, an app for requesting private car service is now disrupting traditional taxi services in more than 26 countries and 60 cities worldwide.13 It was recently valued by investors at around $3.5 billion. Airbnb, which has booked stays for over 11 million guests in hosts’ private rooms, apartments, castles, igloos, and tree houses, sees over 37% of its traffic from mobile devices. Spotify, founded in Sweden and headquartered in London, is one of several music sharing companies that have changed the way we consume music. Apple was forced to respond via their acquisition of Beats (after they had fundamentally changed the music world with iTunes). Tesla cars, now recently available in the UK, is disruptive in multiple ways – their use of electric car technology, their approach to selling cars direct to the consumer without going through a dealership, ability to download software over its cellular connection.
• #5: Cloud, Mobile, Social, Big data are all the rage… Gartner talks about the Nexus of Forces, major (non-technical) news sources cover these topics on a daily basis. But what about the applications – these are the heartbeat of all of these technologies, we use cloud as a deployment vehicle for applications, the value of our mobile devices are driven by mobile apps, social is all about applications that spur productivity, spur collaboration, and Big Data both analyzes data and usage from applications, and provides analytics or other sources of data that are surfaced in an application.
• #6: So what our the demands for modern business applications? Businesses must be nimble – they need the ability to deliver application functionality fast. People must collaborate – people must have access to data that they trust, they can share, data that drives decisions. Organizations must move rapidly – leading organizations leverage all technology at their disposal – cloud technologies (public/private), mobile form factors to support their workforce, etc.
• #7: And now… IT is overwhelmed by expectation (due to consumerization of technology, users demand social/collaboration, users demand ubiquity/ always connected, users demand compelling user experience) IT/Dev resource shortage Increased user expectations Pressure from execs to use technology to innovate / differentiate Support for mobile Etc.
• #8: In addition to the increased demands of the business, there is also an explosion in data… and organizations are challenged to leverage this data effectively to propel their business… The end result is that IT can’t keep pace… We see this in study after study including recent research that we did with Vanson Born - 700 IT decision-makers from mid-sized organisations (100 – 1000 employees) were interviewed in a world wide survey that cut across all major industry sectors… On average 6 months to dev / deploy new app 85% say demand for faster delivery - pressure from execs, sales/marketing, customers / 88% want to deploy more frequently Only 18% say their current processes are agile enough to deliver apps as quickly as they like
• #9: In addition to the increased demands of the business, there is also an explosion in data… and organizations are challenged to leverage this data effectively to propel their business… The end result is that IT can’t keep pace… We see this in study after study including recent research that we did with Vanson Born - 700 IT decision-makers from mid-sized organisations (100 – 1000 employees) were interviewed in a world wide survey that cut across all major industry sectors… On average 6 months to dev / deploy new app 85% say demand for faster delivery - pressure from execs, sales/marketing, customers / 88% want to deploy more frequently Only 18% say their current processes are agile enough to deliver apps as quickly as they like
• #10: So how do we address this gap – many things are happening… Agile, DevOps, etc., are all about building and delivering applications faster and more frequently. I would argue that one way to address this problem is to simplify the development process so that we can 1) make existing developers more productive and 2) that we expand the existing development pool by engaging/enabling technical business users to be more involved in the app dev process. In effect, just as we started the BYOT trend, we need to start the BYOA trend.
• #11: How do we do that? How do we develop compelling business applications faster? Let’s take a look at 9 considerations…
• #12: Infrastructure: applications, databases, virtualization, physical servers, networking & storage Application types: HR, ERP, CRM, customer engagement, business strategy, mobile apps Technology advancements have made it possible for organizations to focus more on building apps. We’ve moved from the day where organizations built their own infrastructure… to the point that we have standard Java / .NET app servers… we now have complete web frameworks… We’ve moved from the point where organizations had to implement and manage their own processes to manage the deployment of applications to the point that we have DevOps tools that automate a lot of these processes. We’ve turned to packaged applications and outsourcing options to speed the introduction of applications and to eliminate the need to manage our own IT infrastructure. A lot of these trends have been driven by the cost side of the equation… but organizations need to consider the revenue / innovation side as well. Organizations need to make decisions about where they fit on the commoditization curve. If they don’t leverage commoditization effectively, they will spend money, time and resource on aspects that won’t provide value. But if they rely on commoditization or take a lowest common denominator approach, they risk outsourcing their differentiation or they risk squandering a potential competitive advantage. Let’s take a look at 2 elements – infrastructure and applications: The industry has moved to a commodity based approach for servers… and there is also common technology that can be used across many of the infrastructure layers… networking & storage, virtualization, databases, etc. Unless you have extreme requirements, it likely doesn’t make sense to roll your own and push your commoditization point low in the infrastructure stack. On the application side, while you can’t look at applications as a stack or in a linear fashion, organizations can make choices about what they outsource as a commodity, and what applications they take ownership to drive competitive differentiation and innovation. Most organizations will be well served to leverage packaged or SaaS based solutions for basic functionality like HR, ERP, and inward facing CRM, but when it comes to applications that drive the customer experience, or applications that provide process speed, business agility, business innovation – you may be better suited to build and manage these applications more directly. Forrester talks about Systems of Record and Systems of Engagements – “The most visible class of these modern applications are systems of engagement (SOE), those software systems that help people identify and take the most appropriate action at their moment of need. In an age when customers have more power than ever, such systems of engagement directly or indirectly support them on their journey of discovery, purchase, use, and service.” Whereas… “1) systems of record (SOR), which store customers’ transaction history and other content and business processes; and 2) systems of automation, which control physical products and infrastructure.” “Systems of engagement are applications that aggregate information from multiple service endpoints, package that information into a contextual bundle, and enable customers to take the most appropriate action. Systems of engagement are most typically mobile or web applications, but they also work in people-mediated settings like call centers or sales force support, where agents or salespeople deliver the systems’ recommendations and actions on behalf of customers.” It could be that the delineation between Systems of Records and Systems of Engagement applications is where your point on the commodity curve should be. Outsource your business process Architecture Roll your own architecture…. Packaged application Java / .NET app servers… Complete web frameworks… HR…. ERP… CRM…. Customer Engagement… Business Strategy… Mobile Apps Mobile Analytics Customer Transaction history & business processes Discovery, purchase, use, service Personalized Applications Databases Virtualization Servers Storage Networking Data Center – mechanical and electrical
• #13: Forward looking organizations are looking at how they can engage the entire business so that they can increase their technology leverage. Traditional organizations still look for the CIO/CTO to provide technology leadership… Forward thinking organizations look at how they can harness the technology acumen of their entire staff. This is reflected in the new CMO – in many cases, the CMO drives the technology agenda and increasingly drives the technology spend. And this makes sense in today’s new workforce – people that enter the workforce are more technical, there is no clearly defined boundary between developers and non-developers. I was speaking to an enterprise architect at a leading technology company and he said “we want IT to get out of the way”. His point was that they want to enable their users – they want to move away from the IT ticketing concept where you open up a work request and wait. He wanted to focus the IT and Developer resources on higher value work. So whether you believe in the Gartner’s prediction that they made in 2011 that 25% of new business apps will be built by citizen developers or not – it’s something that you should consider. Think about the number of apps that non-IT types are building with MSFT Excel, Access, or apps that are built around BI and analytics tools, or apps that are built using Sharepoint, Wiki’s, etc., or apps that are built with a high level 4GL tool… those apps are out there already. And the problem is if you don’t have a strategy, you’ll end up with a Shadow IT problem that you’ll eventually be stuck holding the bag. So what should you do? Should you jump straight to enabling the Citizen Developer? I think a better approach is to leverage cloud technologies and transition there via the development organization. Pick a high-productivity PaaS solution and let your developers use it – learn the best way to use it – speed your more traditional development efforts. Then… Determine what aspects of the platform make sense to expose to technical business user types – pick a discipline and role like marketing analyst, sales operations, financial analyst, etc., and make the platform available to these citizen developer types. Train them and manage their efforts so that you make them more productive – and that you do so in a way that will not exacerbate your Shadow IT challenge. Take a measured, step-wise approach to growing your developer pool.
• #14: While public cloud companies receive the majority of today’s hype – whether it’s Amazon, Google, Salesforce, etc., and while your organization likely started in the cloud based on SaaS applications, you should think how the public, private and hybrid cloud capabilities factor into your overall architecture approach. It’s highly likely that you’ll need some combination of all of these technologies. For example, Application workload should be factored into your selection – applciations that deal with sensitive data / regulatory concerns may dictate the need for a private cloud implementation, or at the very least should prompt you to have control over data residency if you rely on a public cloud implementation. Project type – using the public cloud may be a great place to start pilot projects, run POCs, etc., you may even choose to host all of your development and test efforts on the public cloud… while implementing the production system on a private cloud. When it comes to PaaS, you should consider these items: Select application tools and infrastructure that provides you with cloud choice. While public only options may seem appealing, they limit your flexibility. Beyond the lock-in approach, without tremendous effort, you won’t have the ability to run your applications in your own datacenter, or to implement your own private cloud using other publicly hosted options. And don’t just plan for today, your business requirements may change, you may have different customer, partner, legal, geographical considerations that may force you to make a change later – anticipate this as part of your archtiecture design. Think about taking a hybrid approach to separate your dev/test environment from your production environment – run your dev/test in the public cloud so that you can scale up, tear down, etc., and then run your production application on your private cloud instance. Just make sure that you have a solution in place that allows you to easily replicate your environments on different clouds – that your DevOps process accommodates the move between clouds so that what you deploy to your production environment is the same thing you tested. For app workloads that you run in your private cloud – determine how you are going to scale. For regular growth, it makes sense to scale your private environment – and if your growth is fairly dynamic, make sure you have the measurement and notification capability that you need to scale things effectively – eventually you may want to pursue auto-scaling as well. But for seasonal or peak volume, you may need to architect so that you application bursts into the public cloud. This provides more flexibility and allows you to avoid adding physical capacity that will go unused most of the time. Work with the finance team to determine the financial benefit / tradeoff of using the public cloud. Many organizations can benefit fro the reduction in capital expense that relates to the diminished need of physical servers. Look at this factor as well as other physical infrastructure (space, cooling, networking, etc.) and people management costs (Sysadmin, etc.).
• #15: Organizations are all over the map in terms of mobile development. Some have completed their first generation approach and are assessing their go-forward plans. Some are just starting their efforts and others are in the planning stage. Some organizations want to mobilize existing application functionality, while some organizations want to build new mobile apps. Apps are all over the map as well – some organizations are building customer facing apps, some are building internal applications, some are building both. There is a move afoot to drive the user experience from a mobile perspective – it’s called mobile-first. It’s actually a bit of a misnomer because the philosophy of mobile first is to ensure that the the design experience works effectively across the entire spectrum of digital devices. I think a better name for this approach would be “user-first”, that we design the experience for the user based on his or her environment, the type of application, their work/life-style, etc. Why is this important? Well, we have all experienced sub-optimal application experiences. As a consumer, If we have a sub-optimal experience, we will likely move to another option. This has a direct impact to the bottom line. For employees, we may not have a choice, but the impact of a poor application experience can hurt productivity, it can hurt employee morale, etc. So, either case can be substantial. This isn’t an easy situation address since it is complicated by multiple factors: Device diversity – the number of devices that need to be supported – Android, iOS, etc. Screen size – this isn’t a phone vs. tablet issue, this is an issue for phones – different screen real-estate for different devices. Phone vs. Mobile – aside from the screen real-estate, we see that these are being used in different cases – that should be factored into the design experience. Diverse usage – people use their phones at work, at home, in the car, traveling, commuting, outside, inside, in stores, etc. You should consider these factors based on how relevance of your application. From a technical perspective, there are other challenges: Need to integrate the mobile app into your existing environment – integrating with existing apps and data sources is important – you don’t want your mobile app to be a silo. Selecting the right back-end infrastructure to support your mobile apps – ideally the back-end infrastructure would provide consistency across web and mobile apps – so that you decouple the back-end from the different user interface requirements. The right blend of native or generic web browser application capabilities – while native apps that are written for each device provide the ultimate experience, the cost is prohibitive for your typical enterprise business application. It may be better to go with a hybrid approach that leverages a container based approach that allows you to leverage specific platform capabilties like calendar, contacts, camera, by writing code that is not devie specific. And it’s not just about writing code – organizations should consider platforms that allow them to develop, deploy and manage mobile apps visually, without writing a lot of code. Regardless of the choices that you make, the user experience should be front and center in your design and architecture approach.
• #16: We can all relate to silos – they exist in every business. From an IT perspective, many organizations experience communication and alignment problems between IT and the business. Business is not happy with the quantity and quality of apps. IT thinks the business doesn’t know what it wants, etc. Within IT we often see organizations that struggle with silos – take for example, Dev and IT Ops. IT Ops is brought in late to the game – Dev tends to throw the finished application over the wall to IT Ops. IT Ops is stuck taking the app, deploying it in production, monitoring the application and resourcing the help desk function when the end user has a problem. And Dev isn’t happy with the amount of time it takes IT Ops to provide and provision infrastructure for their new development efforts. This divide has led to DevOps, which hopefully will address this divide. Given these silos, it’s probably best to avoid a mobile app dev silo – or if you choose to have a silo, make sure that you have the process and people in place that can manage the abstraction level appropriately. Here are things to consider: The benefits of a service based approach will help your mobile efforts – if you take an API First approach, the APIs can be used to support your mobile efforts, providing consistency and re-user of back-end business logic that can be used across your mobile and web apps. Some solutions even take a model-driven approach where the user defines the application model, and the solution automatically generates the server components. In addition to providing consistency, this helps minimize the development effort. If possible, think about leveraging a combined infrastructure to support your mobile and web efforts. While many PaaS solutions now offer mobile capabilities, not all mobile support is of equal value. Make sure that the PaaS solution provides the ability to develop a hybrid approach so that you can meet the user experience needs of your application. While you are looking to replatform your applciation infrastructure using cloud principles, it simply makes sense to leverage the cloud to support your mobile efforts. Cloud based options bring the same economic benefits, flexibility benefits, etc. to mobile development. There is no reason not to leverage your PaaS to support mobile. While there are some applications that demand native capabiltiies – gaming, highly interactive apps, etc., most organizations don’t have the wherewithal to build custom apps for each device – and they don’t have the luxury of time that it will take. A good compromise is to take a hybrid approach – this will allow you to develop compelling applications using standard development approaches – the best solutions will allow you go avoid code almost completely via a graphical development environment. To best integrate your development efforts, a single development environment that supports both web and mobile app dev efforts is key. If you choose to keep your mobile team separate – some organizations do this intentionally as Forrester states “to keep a fresh approach, complete major redesigns in under a year, and then gradually socialize mobile”, many of these considerations still hold true. Some organizations choose to keep it separate at the onset, and then they work to integrate the development efforts after they have socialized mobile. In either case, think about the integration points that are necessary to eliminate barriers to success.
• #17: We also researched the data integration challenges that people face as part of our recent PaaS survey. Not surprisingly, we found that Just 10% of all respondents only ever require a single data source for each new application created. Over two thirds (68%) report that they require multiple sources to be integrated on half or more of these applications, For an average application, 81% require two or more data sources Despite this clear requirement, three in five (61%) do not have full access to each required data source. Why is this the case? This is not surprising given the heterogeneity that exists in many organizations, even small ones. And it’s not surprising given the explosion of data – volume, variety, velocity and complexity. This challenge leads to the following problems that were illustrated in the survey: Application development efforts relating to integration take too long, lead to unanticipated costs, and involve too many manual steps. This diagram illustrates the challenge – there are many different application types that are deployed differently. Some apps are deployed in the public cloud, some are in the private cloud. Same with data, data may exist on-premise or in the cloud. Placing the burden on the application developer to navigate this environment and to address all of the different scenarios is a recipe for disaster. You need to think about this challenge as part of your application development infrastructure. This includes the ability for a public cloud app to get to data in another public cloud or to data that you keep on-premise. And your on-premise applications need access to other on-premise data sources as well as data that is in the public cloud. You need to to this securely – without punching holes through the firewall, and you need optimal performance for real-time application support.
• #18: It could be due to the separation between Dev and IT, or it could be that the application is closely related to the business challenge, where the downstream processes are not as closely associated with the business, but in many cases it seems as if the primary focus of the business application process is the development stage. This may be changing with the focus on DevOps, but regardless of your area of focus, organizations need to think about the entire software supply chain.
• #19: Let’s start at the infrastructure layer, it’s important to think about your requirements. For example: Compute, storage (block and object), database services (relatonal, NoSQL, etc.) Operating system and bandwidth (incoming and outgoing requests) considerations Regional support considerations SLAs – uptime for compute and storage Load balancing & auto-scaling support Alignment with your hybrid or private “burst to the public” strategy Alignment with OpenStack or other preferred architectures And finally, and perhaps most importantly pricing. On the opposite end of the scale is SaaS. While there are technical and business considerations, your SaaS application selections will likely be dominated by the business team. They will likely take the lead in the application selection. While you may influence the decision, if your approach is too heavy handed, you risk alienating the users that you are trying to support. Like it or not, you’ll probably be stuck integrating and governing the application – so it’s wise to focus your efforts here. I’m likely biased, but I think your PaaS decision is the most interesting, and given the need to leverage applications for competitive differentiation, the most important to your organization. So, let’s look at the PaaS decision more closely…
• #20: First of all there is a wide range of technologies that fit into the PaaS category… there are PaaS offerings such based on CloudFoundry or solutions from vendors such as Apprenda are focused on deploying, scaling, and managing completed applications. Other PaaS technologies, such as aPaaS are more also focused on the development stage of the application lifecycle. Gartner breaks the aPaaS space into High-Productivity and High-Control solutions that are characterized in the above chart. It’s entirely possible that you’re PaaS strategy will include support for both High-Productivity and High-Control, but you need to drive this decision based on your organization requirements.
• #21: Progress Pacific includes a service based platform that provides the services you need – Community and Collaboration services like mobile, community, visualization, analytics, marketplace Architecture Services like runtime, database, integration, transaction, and I18N services Governance Services like account, monitoring, security, DevOps, Legal/Compliance
• #22: CHALLENGE Changing dynamics in the Retail Industry – required them to rethink and rebuild their ERP and POS applications SOLUTION Develop new ERP/Warehouse management application based on new business processes and industry requirements BENEFIT Off the shelf applications did not support their specific requirements and could not differentiate them – so by building it themselves they are able to deliver on unique business requirements in a timely manner