Spark

Subscribe via Email

Subscribe to RSS feed

Archives

Microservices as a Mobile Development Enabler

A mobile application has very little function without data to work with and enterprise business mobile applications, even more so. This has given rise to the visibility of application programming interfaces or APIs within the enterprise. Businesses are using APIs to allow visibility to certain business data to business partners outside the company. This concept is nothing new, businesses have been sharing data through Electronic Data Interchange (EDI) and Value-Added Networks (VANS) since the 1980s. However, in the last two years, the spotlight has again shown on APIs as the linchpin to support mobile development.

Microservices as a Mobile Development EnablerOne facet of creating APIs to support mobile development is Microservices which are small, single-purpose, server applications and that can be composed together to form other server applications. The idea is that a microservice does one thing well and executes as a standalone application within a server container (which is one of the differentiators between microservices and their larger SOA brethren). A number of IT technologists have equated microservices with the idea of Unix shell pipeline apps in that they share characteristics such as “small”, independently deployed in their own container, may communicate with each other and are loosely-coupled. James Lewis and Martin Fowler of Thoughtworks published an excellent paper that covers Microservices 101:

In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.

You can say that the above statement could also fit SOA but Lewis/Martin call out how microservices are different enough to stand as its own architecture.

One of the reasons that microservices is a popular choice for mobile development is that each service can start out small, the developer can work both sides of the effort, creating both the mobile app and the service to support it, iterating the services to meet the needs of the mobile app and simply deploy the changed service without coordinating with other developers or the service development team.

This leads into the second trend besides mobile development that has pushed Microservices to the forefront which is the shift to DevOps and Continuous Delivery as another key enabler. The reason for this is that microservices support the need for quicker, independent development (no teams), easy rollback, developer-owned (no handoff to the service support team, it follows more of the “you built it, you support it”), and frequent releases.

Microservice allows an easy and flexible way to integrate automatic deployment with Continuous Integration tools familiar to developers such as Jenkins. That is not to say that microservices provide some type of free-lunch; once the size, number and complexity of the services move out of infancy, a number of issues need to be addressed including operational overhead, a higher level of DevOps skills and the complication of managing a large number of services, many of which perform some level of service inter-communication.

SOA has been around for quite a while and it is difficult to remember when it was the new kid on the block. For the most part, service development around REST and the JSON data interchange format has taken hold and microservices has made it easier for the mobile developer to easily and quickly build/deploy the services needed to support a mobile application.

Are Two Pizzas Enough?

2 Pizza TeamsImagine being an executive for one of the largest pizza chains in the world and being invited to a meeting titled “Why Two Pizzas Are Enough”. How would you react? Would you be concerned a few zeroes had been left off? I did a contract role as an agile coach for just such a major pizza chain a few years ago. When it was time to give the executive management team an overview of Agile and Scrum (the specific methodology the company was interested in implementing) I was advised to not call the meeting Agile or Scrum. After asking why I should avoid this I was told that the business was sick and tired of hearing about both Agile and Scrum and they wouldn’t come if they knew what it was about. I used the analogy of two pizza teams to grab their attention and boy did I grab their attention! Every Executive attended the meeting.

In last week’s article “Agile and UX Design: Can they work together?” I mentioned the concept of a two pizza team. In this article I give more definition behind this concept and how it applies to agile approaches.

The two Pizza team terminology was coined by Jeff Bezos, founder and CEO of Amazon. You can read more about his concept and how it has become part of the culture at Amazon by reading the Fast Company article “Inside the Mind of Jeff Bezos”.

What is the two pizza team analogy? In Scrum, and most Agile methodologies, the team is meant to be a small, cross-functional, empowered team of approximately 5 – 9 people, depending on the project size. Therefore when your team has to work through lunch or late into the evening, as you know you do when you work on a project, the company can feed the team with two pizzas. I.e. Two pizza teams.

There is more accountability in smaller teams and they tend to avoid the issue of social loafing. According to social psychology, social loafing is the phenomenon where individuals tend to put forth less effort when working in a group than when they are working individually or coactively. Small teams in which each member is accountable for specific tasks for the project will avoid this concern and hold each other accountable on a daily basis for the work being produced.

There is, on occasion, a concern raised with the small number of team members when a project may be extremely large and require more than the recommended 5 – 9 person team. In this event, review the project goals and determine a team structure in which multiple Scrum (or whichever agile methodology is being used) can be structured reporting into one Project Manager or Product Owner (whichever role title your project is using). In many projects a quick review of the goals or epics will show a natural delineation into individual teams. These teams should be able to communicate with each other, but limit the communication paths necessary between the teams. In other words, if team A is unable to complete their work because they must first coordinate with additional teams the project will stall. Minimizing communication overhead while still encouraging communication between teams is a key strategy to the success of multiple teams within the same project.

Try the two pizza team concept when your organization on a smaller scale first. Something as simple as a meeting in which a decision or consensus needs to be reached or if there is a larger problem which you are attempting to solve, break it into smaller chunks and assign a small team to each chunk to solve. See how quickly and effectively these small teams can work. Not only will your problem get resolved, your corporate lunch bill will go down.

Showing Off Their CSS

In the past few weeks, I’ve seen no less than five different companies publish an article documenting their internal CSS frameworks; it’s a fascinating pattern.  Getting an inside look at how other people (or companies) are organizing code and what tools they are using is a pretty fantastic way to become a better developer yourself.  Take a look quick look.

  1. Showing Off Their CSSGitHub’s CSS
  2. CSS at Lonely Planet
  3. CodePen’s CSS
  4. CSS at Groupon
  5. CSS at Plataformatec

The benefits of having a defined development process are plenty: streamlining your workflow, code reusability, greatly decreasing the amount of time it takes to ramp-up new developers; the list goes on.

What are some of the things you or your company does to organize the structure of your code?

Agile and UX Design: Can they work together? Part One

Diet pills and Agile have a commonality – people want a quick fix to lose weight only slightly more than they want a fix to all their project management issues. Unfortunately, diet pills nor agile are silver bullets to correct either concern. It takes dedication, work and an understanding of the principles behind the body’s metabolism to lose weight. Likewise, it takes dedication, work and an understanding of the principles behind agile to improve delivery of a project. Once you understand these principles you can become a two pizza team, improve project delivery and lose weight at the same time.

This is the first part of an ongoing series attempting to not only bring clarity to what it means to be agile, but also to answer the question, can agile methodologies work during the UX design phase of a project? I have heard arguments on both sides of that debate. Many designers saying ‘no’ it doesn’t work and the more traditional waterfall methodology works best. Why? Because you have to business requirements before you can start wireframes and you have to have wireframes before you can start creative design. Before starting creative you have to have a content strategy which depends on the wireframes, which depends on the business requirements and on and on. While I am not arguing these needs I want to explore the possibility of providing these needs within an agile process.

But, before the exploration of this feasibility can begin let’s first define what agile means. I hear the word tossed about to describe a single methodology of project management or software development. Ask a project team what methodology they are following and often you hear “we are using agile”. What does that mean? Each week we change our process because we didn’t like what we did last week? Or, the client wants us to change how we are doing things because they didn’t like what we did last week? That isn’t agile, that’s chaotic and reactive. So, what is agile?

It’s difficult to define as agile is an umbrella term for multiple approaches to project management of software development projects. At the core, agile is a group of methods that enable small, cross-functional teams to quickly deliver business value in an iterative, collaborative approach. Where change is expected, not feared and where requirements can be expanded upon as the team learns more. Where conversation and collaboration are valued over strict adherence to a set plan defined before the requirements are even made clear to the customer, let alone the team.

The agile manifesto describes the values and principles of agile software development practices and I won’t take the time to reiterate them here, but if you don’t know them I suggest checking out that link. The manifesto itself is made up of four key values supported by twelve principles.

Agile Manifesto Values

Agile Manifesto Values

Some agile methods which exhibit these values and principles are:

• Scrum – arguably the most popular
• Kanban
• XP (Extreme Programming)
• Lean Software Development
• Feature Driven Development
• DSDM (Dynamic Systems Development Method)
• Crystal

This is not an exhaustive list of all agile methodologies, but some of the more popular ones currently in use. Which of the approaches to use depends on the team’s knowledge and expertise in each methodology, their culture and sometimes the project goals.

Making a move to agile is a cultural change that impacts the entire organization, not just the IT department. It’s a marathon, not a sprint. An evolution not a revolution. There is compelling evidence that iterative methods reduce project risk, compared to more traditional waterfall approaches. Next time we’ll move into the discussion of bringing Agile and UX together.

In the meantime, have you been involved in a cultural shift to using agile? What pain points did you find and how did you resolve them?

Internet Explorer: To Support or Not to Support?

Microsoft published an article on their Internet Explorer blog yesterday that discussed their plans for supporting older versions of IE, and the web development community has been blowing up ever since.  I have seen many eager Interneters making loud claims to the tune of, “IE8 is dead!  We no longer have to support older versions of IE!”  However, it’s very easy to get caught upInternet Explorer Logo in the pandemonium or start bandwagon-ing and miss the actual facts of what is and will be happening according to Microsoft.  I want to clarify some things and set the record straight before we all hang up our Windows XP virtual machines. Read the rest of this post »

Abstracting the UI Layer

Last month at the IBM Digital Experience Conference, Shyam Sunter, a Perficient Technical Solution Architect, and I presented on a method for abstracting the user interface code (HTML, CSS, and JavaScript) out of WebSphere Portal. A key part of this presentation was going over why this abstraction was important.. It’s of my opinion, that abstracting the UI code out any platform, be it WebSphere Portal, Sharepoint, SiteCore, what have you, is vital for building modern, cross channel digital experiences. Supporting an abstracted UI layer is a common practice for many digital platforms, especially in the start up space. It’s time that the enterprise world starts to consider adopting this practice as digital solutions become more pervasive and complex.

 

Diagram showing the various layers that make up a user's digital experience.

Elements of User Experience

 

For a long time now, User Experience professionals have been working in a world of abstracted layers. This is best illustrated by Jesse James Garret’s famous 2010 diagram of the Elements of User Experience. Even when the web was simply made up of two layers, structure and style, designers used these abstracted layers to map out the overall structure, information design, behavioral touchpoints, and visual design elements of a given solution. As the web matured and additional technical layers were added, such as behavior, content, and contextual awareness, these layers became more important for us to work through and support. Modern digital solutions, such as Disney’s My Disney Experience, Airbnb, Uber, and many many more, are ones built on top of these abstracted layers so that their overall solution is more scalable and maintainable.

Modern Web Architecture

Several other benefits manifest themselves as well, including:

  • Design teams being given ownership and control over the development and deployment of the user interface layer. Design is naturally an iterative process, which involves creating and testing various solutions to a given problem. Having control over the UI layer, gives design teams the freedom and flexibility to try out new solutions and to simply “play” with the overall design.
  • Publishing UI code more frequently. With the control of the UI layer living in the hands of the design team, code can be pushed out more “real time”. This doesn’t always mean to the production environment, but users and stakeholders are able to touch, feel, and play with a new design quicker and in a realistic environment.
  • Easier to support cross channel solutions. It isn’t news that the days of people being chained to a desktop computer and chair are over. But, the new world of multiple digital devices and varying resolution sizes is a still new, and it’s really complex. By supporting a stand-alone UI layer, it’s easier to contextual deliver the right design for the right environment.
  • Proper support for accessibility standards. Accessibility doesn’t just apply to UI code, but a good chunk of it does. If you don’t have a backend platform interjecting its own code or compiling code that a UI developer has written, many accessibility issues can be addressed in a more streamlined fashion.

 

Ultimately why does having an abstracted UI layer matter though? Because there is no such thing as just having a website or just having an app anymore. It’s about providing a digital service that people can interact with, play with, and enjoy at any time from any device. Many things go into ensuring that the resulting experience is a pleasing one, but taking the time to build a UI layer that isn’t, at least fully, dependent on a backend platform is one of the key methods for properly serving people who use your digital solution.

Designing From A Fresh Perspective

As a designer, its easy to fall into patterns that conform to established models. But to truly innovate, you must bring a fresh perspective to every design challenge. I was recently reminded of the value of a fresh perspective, when my 7 year old daughter took on the challenge of making a computer for her American Girl Doll. Because we all know that any self-respecting doll, has gotta be connected.

IMG_3311

American Girl Doll Using Her Laptop

However, this was not an ordinary computer. It was a Mac, which was already enough to make me proud. But it was also customized to her doll’s very specific needs. First of all, it was purple, which is the doll’s favorite color, it was also sized perfectly so that it could fit into her purse and it even had a rear facing camera to take pictures of the other dolls while she was on “Facebook.” But what amazed me the most was the keyboard layout. Yes it included most of the typical numbers and letters that you’d find on a keyboard. However this keyboard was also personalized. It had special keys for her email address, zip code, and Facebook username “in case she got tired of typing.” This really made me realize how much I hate typing in my email address all the time, especially on mobile devices. Wouldn’t it be great if I could have a single key that take care of that for me? Yes, I know most web browsers retain email inputs to support an autofill function, however mobile browsers typically don’t support that capability as well. And in mobile interactions, that capability would have most value.

IMG_3313

Personalized Keyboard

In designing her computer, my daughter never considered the limitations that come with a standardized physical keyboard. In her mind, a computer should be customized to meet the needs of the user. And in today’s world of virtual keyboards and personalization features, there is the opportunity to make that reality. It might even change the way we think about our personal devices. So in your next project, try injecting a fresh perspective and you may be surprised with the results.

 

 

 

 

Android Version Deprecation

The latest version of Adobe Cordova was released today (v. 3.5) and perusing through the release notes, I saw that they had dropped support for iOS 5, leaving only one major previous release (iOS 6) and the current release. In the past, Android developers have been plagued by the slow release of new versions of the Android SDK to existing Android phones. It has only been in the past year or so that a significant number of developers have moved off supporting 2.3.3 (Gingerbread) and below, making the lowest androidversion number supported being 4.0.3. The question for Android developers is: how aggressively can they move off of 4.0.3 to the next major release, 4.1?

Taking a quick check of the Android smartphones available through the various carriers, none of the phones are lower than 4.1 but a number are at 4.1 (example, the LG Enact and Motorola Droid RAZR M) so, unlike Apple, we as developers cannot move back to only 4.2 and eliminate phones that are still being sold by the major carriers. In all likelihood, the 4.0.3 phones are those who are waiting for their 2-year contract to come up, knowing that the phone will be not be updated by the carrier or OEM. Dropping 2.3.3 loses a developer about 16% of the market but gains in terms of lower bug count (quite a few issues are performance related, trying to use a modern mobile app on older hardware) and a wider selection of third-party tools (which have abandoned 2.3.3 and many are 4.1 and above).

The key issue is supporting 4.0.3 and its 13.4% share. The developer has to determine how resource-intensive the app is and what is the risk of users trying to run it on 4.0.3 (which are also resource-limited) and the subsequent crashes due to memory errors. It is difficult to justify to management a proposal that shuts out almost 30% (2.3.3’s 16.2% and 4.0.3’s 13.4%) of a customer base but the bigger question is: does it make business sense to support a project when the funds required exceeds the return of investment and the risk of poor acceptance in the marketplace when the app’s performance requirements exceeds the user’s hardware at the low end of the curve?

One other consideration I failed to mention is usage by the international market. If the mobile app is targeted outside of the United States/Canada, many lower-end Android phones (white-box, introductory) sold in India, China and Africa are still using 2.3.3/Gingerbread. In the case of tablets, even the low-end 8 GB/under a $100.00 models are supporting Android 4.1 and above (source: Walmart.com).

Posted in Android, Mobile, Musings

Myths & Facts – Websphere Portal and UI.

Having worked as a front end developer, integrating the UI with backend systems, I am presenting below some of the myths and facts concerning UI (html, css, javascript, images, fonts) code integration with websphere portal and a few best practices one should follow -

Myth – Websphere portal is not compatible with latest front end frameworks like bootstrap, foundation, jQuery Mobile, etc.

Fact – Websphere portal is completely compatible with all the latest front end frameworks and there should be no reason why one should be concerned about including the front end framework in the portal. Basically, the front end frameworks include a css file, which is responsive, follows a grid system, provides styling for UI elements and takes care of accessibility and cross browser compatibility to an extent. The html in the portal will only be referencing the class names that are defined in the framework’s css file, enhancing the user experience and this css file is included in the portal theme.

Myth – Websphere portal is not compatible with jQuery and associated plugins.

Fact – Websphere portal comes with dojo javascript library as the default framework and many of the portal elements like WCM, use dojo’s javascript functionality for client side manipulation. However, on starting a new project, there are certainly workarounds available to make sure portal’s dojo does not interfere with jQuery. On a websphere portal 8 project – starting from scratch, if there is no dojo being used(by the portal theme and associated portlets) but only referenced in the portal, then jQuery should be working fine without any issues. We might see some conflicts if we try to use both dojo functions and jQuery functions, but using only one of them with the other being referenced (like portal needs dojo reference), should be just fine.

Myth – All the css, javascript, images associated with a portlet should be inside that portlet.

Fact – This is a bad practice. All of the css, behavioral javascript and images for each portlet should be in the portal theme. Because, if you have 3 portlets on a page, then the page load would take a long time, as when each of the portlet loads, its associated css, js and images will also load then. But if you are loading all of them at the bottom of the page in the theme, then the portlets would be rendered without the interference of static assets, which get loaded at the bottom. There are various compression and minifying tools available to reduce the load size and http requests of these static assets. This way, an UI developer has direct access to all of the portal’s static assets, in the theme, can make changes and deploy, while really not worrying about making changes to each individual portlets.

Myth – To make a change in the css file, this should be done in the portal theme, deployed to QA, tested and then served to production.

Fact – In today’s web development world, where the UI is constantly changing and more changes to the css is needed as expected earlier, the changes to css in the theme, deployed, tested and served to production is a tedious and long process. As an alternative, the css file for the whole portal theme can reside in a web server or IHS (IBM HTTP Server), and then referenced in the theme. Both the UI developer and the portal developer should have access to this web server, so that changes can be done directly to this css file and pushed to any environment without the need for a deployment. Same goes for library javascript files and images.

Best Practices a Front End Developer needs to follow while working with portal theme.

1. For prototyping, use a build tool and a generator such as yeoman build and grunt tasks. This would throw up production ready, testable, minified, compressed static assets – css, images and javascript.

2. Move the css to a web server or IHS and reference this css in the theme from the web server so that, any change to the css does not really require a theme deployment. All it needs is front end developer access to the web server. Same goes with library javscripts (jQuery, plugins, etc) and images. To swap a logo, it can be done in the images folder on a web server, tested in QA, pushed to staging, verified and finally served in the production.

3. Make sure there is no inline javascript inside the portlet, as this greatly affects page load performance. All the javascript should be loaded at the bottom of the page. There should be no library files in the portlet, as this would result in conflicts between different library versions among different portlets.

4. If you are parsing large json data and integrating that with the html in the jsp of the portlet, then just throw up the json on the portlet. Make use of handlebar or mustache templates to parse the json and inject that json data directly in the html. This helps in separating the html from the data and also any changes to the html can be done without altering backend logic.

Minimal Viable Product

In a conversation the other day, the focus was around the integration of the Agile methodology with Lean Startup and the cycle of build > measure > learn and how concepts from Lean Startup can complement an Agile software development process. One of the intriguing ideas that carry over into enterprise mobile development is a Minimal Viable Product or MVP. Quite a bit has been written this year about moving to a “mobile first” Minimal Viable Productenterprise, especially as the threshold of “7.1 Billion people and 7.1 Billion mobile phone subscriptions worldwide” has been reached. Corporate IT needs to adapt to this new way of working or run the risk of employees and managers bypassing the IT organization and creating a large shadow IT environment. There have been numerous examples in the past, the one that comes to mind is the Microsoft Access-based systems that cropped up in enterprise departments in the 1990s when IT could not meet the needs of business and so departments created their own IT systems and thus, silos of data with no interoperability. Corporate IT needs to get ahead of this new wave and demonstrate to the business that they are the right organization implement and manage it. It is imperative for IT to embrace mobile by examining how to enable mobile applications and understand the challenges of a “mobile first” environment. The question becomes, how does IT do that?

So, back to the original topic which was the Minimal Viable Product or MVP. IT needs to work with business to identify problems that are occurring within the organization and look to solve it through mobile. In the case of software development, a minimal viable product (MVP) is a software product that meets the minimum requirements of the end user so that these users can test the product and offer immediate feedback to the mobile development team to iterate on. The feedback is reviewed and incorporated into the next build of the product. Releasing the MVP frequently demonstrates to the end users that a) they have a voice into the mobile app’s design and b) the IT organization is attempting to meet the mobile needs of the business. Creating a number of MVPs targeted at various segments of the business user community with an organization allows IT to understand what these groups are looking for, what is useful and how the IT infrastructure needs to adapt to support mobile. Those MVPs that “scratch the itch” of the user community can be further developed into a valuable enterprise mobile application and discard the ones that do not add value.

One word of warning however, as Abraham Wallin pointed out in his article: Lost in Translation: The Minimal Viable Product, the word “Viable” seems to be pushed into the shadows of “Minimal”. A minimal viable product cannot be poorly designed, all of the learning and feedback from the end users is lost and it will be difficult to get the end users engaged for any subsequent releases or other mobile products created by IT. Creating an MVP requires an entire team of UX, interface design and development so that, even though the product may only have a subset of functionality, it meets base quality and usability standards.

Posted in Mobile, Musings, Trends