Building Blocks of Your Enterprise Mobile Strategy

Given my current focus on Multi-Channel architecture & technology programs for Retail and Logistics customer in UK&I, I am often on a look out for new ideas, trends and business case studies. This interest took me to the IBM Enterprise Mobile Summit earlier this week in London Southbank. It was a compact but impressive gathering of Mobile industry experts, suppliers and consumers. It did help me crystallize my thoughts around Enterprise Mobile Strategy which I am trying to summarize in this blog post.   
When an Enterprise (commercial organisation) makes an investment decision to develop a Mobile Strategy (e.g. Mobile Applications or Apps) and related products or services, it should do so based on strategic enterprise intent (or in certain instances tactical response). This investment should take into account a number of stakeholder perspectives such as Functional, Development, Delivery, Operations, End-User Consumer and the Market.


IBM MobileFirst

The Strategic Intent and drivers behind Enterprise Mobile Investment – 
Before committing funds on Mobile strategy a valid question to ask is, what is your Enterprise attempting to achieve by mobile investment? For instance do you see mobile evolving as one of your primary channel to market? Are you attempting to gather insights from mobile data which may provide new opportunities for product and services expansion? 

Or are you simply trying to increase your business transactions though Mobile media. In some instances it may be seen as a media for extending the brand experience for more personal shopping or browsing experience.


The Enterprise Functional Perspective – If the purpose of Mobile strategy is to address internal organisation efficiency then the functional objectives need to focus on employee and organisation productivity enhancement. For instance how can a Mobile App transform, optimise internal work flow and may be also enhance the customer interactions. KPIs here could be reduction of complexity, reduction in wastage, improving quality, faster time to market etc. As I observed in IBM session, some of IBM customers are using the Mobile strategy to extend Enterprise business network in new ways. For instance an Italian organisation leveraged Mobile Apps to find promotions in their network and connected people to these promotions. Michael Gilfix of IBM in this session also cited IBM’s own example of how Mobile strategy is driving next level of productivity by acknowledging its global workforce segmentation.

The Development Lifecycle Perspective – During the session both Michael Gilfix of IBM and Jessica Figueras, a Mobile Industry Analysthighlighted a point that there is a difference between creating conventional Apps and Mobile Apps. Mobile development and developers need to understand the Mobile App consumption patterns, workflows and user interaction in different ways. IBM briefly shared their Mobile Development Lifecycle process which comprises of iterative phases such as; Design & Develop, Instrument, Integrate, Test, Scale & Certify, Deploy, Manage, Obtain Insight and back to Design & Develop. Jessica made a good point that Mobile Apps are becoming more and more complex and they need Enterprise Architecture underpinning them to be successful.


The IT Delivery and Operations Perspective – The above point about Enterprise Architecture requirements extends into the Operational and Delivery aspects of IT too. Challenge of Fragmentation is particularly important; how best to serve different fragmented devices to serve multi-channel experience which is a different challenge that Web Apps where one size often fits all consumers. Michael was also keen to point our Security and Access control aspects such as Loss of control over distribution, impact of BYOD, Control of data and access as code often would run in environment outside of Enterprise control. From the customer satisfaction perspective, the end-user of Mobile Apps will look out for and increasingly expect consistent multi-channel experience. e.g. Airline – phone, kiosk, in-flight, travel experience.

The consumer perspective: Creating compelling mobile user experience – Ali Al-Shakarchi, the UX Architect and Strategist from IBM had some very interesting themes on this perspective which can be argued as the most important factor to make Mobile strategy successful. He highlighted the fact that, user expectations are high and user tolerance is low when it comes to Apps as the competition is fierce, an alternative App is a tap away. Some of the tips which Ali shared were; Stay Relevant, Keep it simple, Build richer experience, Think innovation, Optimise for mobile, Create end to end experience, Be more social and evolve on an ongoing basis in a smart way.

Some of the demos / case studies during the session further underlined some of above points. The Barclays Pingit case study and how it is driving the C2C is a prime example of how Apps can bring success and create new Operating Models for large Enterprises. While the Tealeaf demo effectively showcased the power of analytics behind smart Mobile strategy. 


One of the key takeaway for me was, Why limit Mobile conversations to IT? Focus must be on exploring business opportunities & enhancing business capabilities”. Iwould like to congratulate IBM for putting together a smart, effective and useful summit. I certainly hope to apply some of the above lessons learnt for my customers in Retail and Logistics in near future. 

For more on IBM Mobilefirst read here

Whence, Angels?

As you’ve read over past couple of years, we’ve started investing in a hybrid Angel/VC model.  Lots of risk, lots of upside, and lots of fun new things to learn.  Applying Capability Driven Methods to management from the start has been both f…

Smart Agile Delivery

I was interested to read the recent McKinsey report on disruptive technologies. McKinsey identifies twelve potentially economically disruptive technologies including the Mobile Internet, Automation of Knowledge work, Internet of Things, Advanced Robotics, Next generation genomics and so on. The report also calls out general purpose technologies as ones that propel steep growth trajectories (think Steam or Internet) – that can be applied across economies and leveraged in many more specific disruptive technologies. Not surprisingly they don’t include software development in either list. The closest they come is with the automation of knowledge work, but this is restricted to artificial intelligence, machine learning and natural interfaces like voice recognition that automate many knowledge worker tasks that have long been regarded as impossible or impracticable for machines to perform.

Is this omission something we should be concerned about I wonder? While software development “practices” have been developing very rapidly with the adoption of Agile methods, it is a reasonable conclusion that software development “technologies ” are not undergoing dramatic changes that might qualify as disruptive. Yes there’s lots going on; in fact there’s a profusion of new languages, frameworks and databases, many open source initiatives, that are progressively specializing development technology. In addition there are significant advances in life cycle management and test technologies. But there isn’t any indication that these new technologies will have high economic impact in terms of dramatic improvement in productivity or quality. Or have a significant impact on the vast economic problem inherent in the worlds legacy systems. Rather there’s a huge proliferation of development diversity and some might say complexity.

Don’t get me wrong, I am not looking for a problem to solve. It’s clear that while smaller Agile projects are fine for tightly targeted problems, most organizations have struggled to scale Agile to larger projects and or enterprise class projects. The increase in dependencies and complexities become overwhelming and the probability of failure increases proportionately.

What’s needed, by larger projects is not process automation, but automation of the deliverable that allows the project to manage the dependencies at the model AND deliverable level. This raises the level of abstraction and can deliver dramatic productivity and quality improvements. As it happens there is a technology that can do this, but strangely it seems to be something that many people have already consigned to the trash heap of “been there done that”. I’m talking about Model Driven Development (MDD). There are many reasons why MDD has not succeeded in gaining widespread acceptance. It is actually extremely complex and requires considerable investment to establish. And in fairness it has been promoted primarily as a deliverable transformation and code generation tool. And many people will say, Oh NO!!! That’s just reinventing Case Tools all over again and we don’t want to go there.

But before we consign this technology to the trashcan of yesterday’s technologies, we need to take a hard look at what you can do if:
A. you have leaf node detail models in the asset repository that are tightly bound to execution deliverables.
B. you use best practice modern architecture with all functionality delivered as service bearing capabilities that minimize dependencies.
C. you can automate to a significant extent the population of the repository with harvested knowledge about legacy applications at that same leaf node level of detail.
D. you can run large scale, full life projects with full iteration of business, architecture, design and development models. (note here this doesn’t mean fully integrated and transformed models, we have gotten a lot cleverer over the years.)
In an Agile context this allows you to iterate functionality at extremely low cost, both in delivery and evolution life cycle stages. In fact experience shows it transforms the development project into an evolutionary approach in which you can really architect and build what you know and evolve to the optimal solution.

Model driven as a concept has been around a long time. Most developers (tell me they) don’t like model driven because it won’t handle complexities; because it diminishes developers’ jobs to be more mundane; that it produces poor code and so on and so forth. But the McKinsey report speaks to the inexorable progress of technology and the inevitability that as technology changes peoples jobs change or disappear. You are either on the train or under it.

Right now Agile MDD is probably only justifiable for the very large, complex projects. But as the case studies start showing higher success rates, with dramatic increases in productivity and quality, and the level of up-front investment is reduced as the capability is productized, we can expect to see the MDD project footprint to expand dramatically. Again the McKinsey report is incredibly bullish on the economic outlook for technology, and information technology in particular as the key general purpose enabling technology, and it’s clear that Agile processes alone are inadequate to support the ever increasing demand.

Being disciplined is for school kids; it’s time we got smart about how we deliver complex services and systems at scale.

McKinsey & Company: Disruptive technologies: Advances that will transform life, business, and the global economy. “Not every emerging technology will alter the business or social landscape—but some truly do have the potential to disrupt the status quo, alter the way people live and work, and rearrange value pools.”