The question of why innovation and business agility are vital –and independent is one that is top of mind for many organizations.
Business agility is essential to survival. With economic uncertainty everywhere, and disruption in many marketplaces, businesses need to respond fast to change. A key enabler for this ability is an IT function that is inherently good at innovating. IT must produce ingenious ideas that will facilitate the required fast business response, for example by equipping the workforce for mobile working. There are any number of innovative uses of mobile technology: for example, a sales person can take and personalize an order while walking around a shop with a customer; a doctor can receive real-time information about a patient’s vital signs.
IT innovation is essential to business agility. However, you also need agility before you can innovate in IT or anywhere else. Which comes first is hard to judge. Organizations tend to start life with both agility and innovation. However, as they get bigger, their agility tends to become constrained for various reasons. Hence their rate of innovation declines, creating a vicious circle.
Complex though the relationship between innovation and agility is, we can probably agree that both are vital to a healthy business, and particularly vital when a business is contemplating digital transformation (where the organization rethinks aspects of its existence to take full advantage of digital technology, rather than simply automate the existing way of working). Digital transformation implies that a business must be able to innovate digitally to overtake the competition, with enough agility to reshape itself around the resultant landscape. An agile IT department has the ability and opportunity to create what the business needs – or else to go out and find it fast.
This blog post is the first in a series based on the paper: Agility and Innovation in Application and Mobile Development.
This week, Uniface exhibited at the Gartner Symposium held in Barcelona. Our team was composed of representatives from marketing, sales and management, with the aim to promote Uniface, whilst also attending sessions held by Gartner and its sponsors. We also took the opportunity to interact with many other organizations that were exhibiting. We embraced the chance to speak to strategic decision makers, during which we had a number of very good conversations, illustrating the unparalleled strength of the Uniface platform and how it addresses the ‘challenges that keep CIOs up at night’.
Wemet many new organizations and partnerprospects as well as existing customers, and lots of people who are part of the Uniface ecosystem. Some of those we met started their careers as Uniface professionals, a selection of which were over 20 years ago.They remained happy to see us going from strength to strength. We also met a world famous footballer!
Having spoken to one Gartner analyst, a key message that came across showed that the world is reacting to the concept of ‘business/mobile moments’, which manifests itself as having smaller focused apps that do one thing well. The huge monolithic applications we know today will transition to API services (i.e. a strong integrated backend) and there will be more targeted single function mobile apps. These will compose the enterprise mobile solutions of the near future. This significant change is touching many parts of the IT industry and the way consumers interact with technology.
To achieve this goal, it is important for organizations to explore and embrace modern approaches, including topics such as Agile, DevOps, Continuous Delivery etc…, all with the goal to improve software quality and the velocity of delivery. Annual release cycles of new solutions have become less desirable, with our industry tending to move to small incremental releases, regularly. Consumers are not worried about version numbers, they just want continual improvement. Given the proposed small changes with each regular release, solution adoption will be better accepted, because each change, although continual, will be gradual. Things will ‘feel’ familiar and evolutionary, rather than creating potential rejection through revolutionary change. This does not suggest the complete end to significant updates by the way.
Now this may sound like a big change to an organization’s way of working…..it is. So how do we address this is a sensible way? One answer is to takeGartner’s bimodal approach. We work in the new way for all new development and innovations, while at the same time continuing in the more traditional modes for existing items, then transition this old style over time. I’ve simplified bi-modal somewhat, however I hope you get the basic idea.
I spoke to a second analyst who also provided some good common sense reminders we all forget from time to time e.g. “What is the best reason to try and reduce the cost of IT?” Some would say “to improve profits.” This seems like a sensible answer and can be, however, it isflawed. A better answer is “to allocate more of the IT budget to new innovation instead of regular maintenance.” Studies suggest up to 92% of resources goes into maintenance, leaving only 8% for innovation. Itis innovation that makes the difference and yields success.
In a conversation with a third analyst, more aspects about future directions were discussed. Hot topics that came up were API’s (…second nature for Uniface), legacy integration/reuse (…another walk in the park for Uniface), web and mobile development (…please give me a challenge) and aPaaS (…you got me!). The last topic is very interesting and something for us to really think about. The market still faces challenges in this area and CIOs are also ‘kept awake at night’ by this. We also talked about the transition from traditional desktop GUI’s to web based and mobile. The trend is rapidly accelerating with the vast majority of new projects now being targeted at API services & mobile, whether that be phones, tablets, wearables or web.
Given the four days spent interacting with many new analysts & organizations, I could write endlessly, so I will stop now and save somefor another day. In the meantime, enjoy some pictures.
I often hear the phrase “Developers are a commodity”. Statements such as this are supported with reasoning along the lines of “The architects/experts will do the analysis & design, while the developers just cut code.” The developer is therefore seen as a pseudo disposable entity, with no key differentiators amongst peers; low skilled and readily interchangeable.
It is easy to see how these ideas have evolved, especially when we compare our industry to others. However, these metaphors feel fundamentally flawed. For some industries other than IT, the low level of detail provided in plans yield quasi-robotic implementation, especially as the design can only be interpreted and realised in one way. In IT, whatever methodology / framework you choose, the developer invariably has to make choices.
So, maybe there is room for some commoditisation? However, is the industry as a whole making a large sweeping judgement, followed by misguided, potentially costly decisions, when referring to IT developers as a commodity?
Application performance has always been an important topic in Information Technology, however often seems to be neglected.
So, what is performance? A simple abstraction is, “how much, in how long.” This can be broken down into many technical metrics e.g. efficiency, throughput, utilization etc… however it is often easy to forget the emotional measures e.g. the perceived performance, time to action, usability, number of clicks etc… . “How much a user can achieve, in how long” is just as important as “How much a computer can achieve, in how long.” The fastest solution is of little use if it takes the user an eternity to use it. Think how much quicker you are able to use many applications once you learn the various shortcuts e.g. CTRL+C instead of (move mouse)->Edit->Copy.
Over the years, there have been many views on when it is best to think about the performance of an application. A common approach has often been to “test at the end and fix performance problem then, rather than architecting for performance.” The core concept here is that for the vast majority of applications, raw performance is not a critical factor for much of the functionality, so why waste effort addressing performance upfront where it is of little impact?
At the other end of the scale, raw performance can be a key success factor for the majority of the application logic. This makes it important to architect for performance and regularly assess. One interesting formal realisation of this is ‘Performance Driven Development.’
Which approach is best? It all depends.
Many areas require thought when thinking about performance. It is easy to immediately think about individual algorithms and routines, however the higher level technical and physical architecture require careful consideration too. Things such and caching, load on demand, batch processing, asynchronous & parallel processing, machine sizing, network architecture, component distribution etc… can all have a huge impact on the application performance. From the user perception side of things, error prevention, self-diagnosis, UI consistency, visibility of system status etc… can also have a huge impact.
If we take “Visibility of system status,” this can quickly improve the perceived application performance. One example of this is adding a progress bar. Many studies have shown that users consistently feel an application performs better when they can see the progress. Further to this, for a fixed amount of time, the rate at which a progress bar fills dramatically affects the perceived change in performance. Observations suggest a progress bar that increases at the same rate, or a progress bar that accelerates towards the end, provoke better results in user perception. A bad choice here can however have the opposite effect and give the impression of worse performance.
In conclusion, performance is a wide topic that goes beyond simply making the quickest algorithms. There are both technical and emotional factors to consider. Like much in Information Technology, it is important to remain pragmatic when considering the many factors, along with finding a balance between architecting for performance versus tuning during testing.