Mobile is Hot ! But be aware ...

I see it in a lot of projects but also I see that it is handled just like testing in the beginning: "oh we estimate some extra days and we also go Mobile !"

Of course this is not the case, it can be a project on its own.
There are a lot of choices to be made, some of them are:

  • Which mobile platforms do we have to support?
  • What are the performance requirements?
  • Do we want to develop once, run anywhere?
  • Do we want to use native functions of the mobile OS?
What I also see, is that more and more BPM/Integration platforms are going to support it.
But then again the Mobile experience is somewhat different than the Browser (and Desktop) experience.
So depending on the requirements of the Mobile App, the platform can suffice or not.

I will shortly describe some platform examples.

OpenText Assure

This is a BPM platform that supports Mobile. However the UIs are running within the browser app of the mobile device. The advantage is that it is developed once, and runs on the desktop and iOS, Windows and Android mobile devices. The consequence is that no native functions can be used.

OpenText Process Suite

This is a BPM platform that supports mobile application development. The following picture gives an architectural overview.

The architecture uses some open source frameworks to implement mobile apps.

Oracle ADF Mobile

Oracle Fusion has extended its Fusion stack with ADF Mobile. This framework is also based on open source frameworks.

Tibco Silver Mobile

This is a development platform to develop mobile apps. It adheres to the principle develop once, run anywhere.


Windows has several development environments for mobile development. Windows has a Windows Phone SDK and also introduced a web based development environment: Windows Phone App Studio.
Of course these tools are all for the Windows Phone.


The development of Mobile apps must not be taken lightly and must sometimes be seen as a separate project. Most of the platforms in the field have separate development environments for it and can be developed as separate apps next to the normal UIs.


Book review: Continuous Delivery and DevOps: A Quickstart Guide


I wanted to know more about DevOps because I agree with the fact that we need to coorporate more and remove the barriers between departments. In the end I was a little disappointed by this book. It gives some high level tools and techniques but it could be much more ...

In my opinion a change would be that someone from Operations will really participate within the project team and looks at it from an operation point of view. This way also these requirements will be taken into account and the system will be more easy to operate.
However there were also some interesting chapters so lets review.


The book contains 7 chapters:
  1. Evolution of a Software House
  2. No pain, No gain
  3. Plan of Attack
  4. Tools and Technical Approaches
  5. Culture and Behaviors
  6. Hurdles to Look Out For
  7. Measuring Success and Remaining Successful

Chapter 1 - Evolution of a Software House

As the name already suggests, this chapter is about the evolution of a software house. First it is a small company with no hierarchy and everybody knows each other. This makes communication easy and the releases of the software are coming fast. It is fun to work within such companies. But then it begins to grow and processes are needed. This is the beginning of a slow working company.

Chapter 2 - No pain, no gain

This is a chapter about organizational change. Investigate what is going wrong. It discusses some tools and techniques how to investigate the organization.
In my opinion not really about DevOps but more on change management.

Chapter 3 - Plan of Attack

This is again a change management chapter in which is explained how to communicate a new way of working. Setting the goal and visions and communicating this within your organization.

Chapter 4 - Tools and Technical approaches

This is an interesting chapter about the tools and techniques you can use to implement DevOps. To name a few:
  • Source control tools
  • Code reviews
  • Continuous Integration
  • Small increments
  • Test Driven Development
  • Automatic builds and testing
  • Architecturing the solution (loose coupling)
  • Provisioning
But then again these are just the tools and techniques development should already been using, when developing quality software. 

Chapter 5 - Culture and Behaviors

This is a chapter about the soft side of DevOps. It discusses about:
  • Openness
  • Building trust
  • Collaboration
  • Rewarding good behavior
  • Transparency

Chapter 6 - Hurdles to Look Out For

A chapter about change management and about some theoretical change curve theory.

Chapter 7 - Measuring Success and Remaining Successful

This chapter discusses some tools to measure. To name a few:
  • Code Coverage
  • Code complexity
  • Commit rates
  • Unused Code
  • Coding rules
  • System monitoring
So also the things I would normally recommend.


The book was easy to read, but a lot about change management. Don't get me wrong, this is very important but there are other books about this subject. There were however some interesting chapters.
Some eye-openers within the book for me:
  • DevOps has impact on many departments: marketing, planning, development, operations, sales and HR.
  • DevOps = Working Together, DevOps != Getting developers do the operations tasks
  • Monitor the progress of the DevOps project