As we transition from one year to another, it is customary to look back on the past year and begin to consider what might unfold in the year ahead. We are in a period of massive technology-driven disruption in the ERP market and this past year will undoubtedly be remembered as the year of artificial intelligence and chatbots. However, when it comes to developing technologies that truly change the way organizations operate, the hype of the simplistic call-and-response chatbots we saw this year will likely be just a small blip on a much longer journey towards true AI. Here are some thoughts from Unit4 on what the ERP market can expect in 2019.
As early as the ’90s, businesses and analysts alike have foretold the death of the ERP system. Over 20 years later, however, ERP is still alive and well. Globalization, digitalization, the internet and a whole host of other technologies have made it virtually impossible for businesses to move away from ERP. There’s simply too much critical data housed in the underlying databases for elimination to ever be a viable option.
Software multi-tenancy refers to a software architecture in which a single instance of software runs on a server and serves multiple tenants. A tenant is a group of users who share common access with specific privileges to the software instance. With a multi-tenant architecture, a software application is designed to provide every tenant a dedicated share of the instance including its data, configuration, user management, tenant individual functionality, and non-functional properties.
Estimating rewrites is hard, and frequently developers got a tendency to underestimate such a task – as, in their mind, they know exactly how the system should work, as they already built it once. This holds only if the rewrite is 1-to-1 rewrite – meaning you are constructing a similar solution from both an architectural, deployment and functional perspective. But if that is the case, why then even bother rewriting?
Moving from an on-premise single solution to a super-scalable cloud based solution requires a complete new architecture and equally important, new deployment scenarios. The latter needs to factor in continuous deployment such that it will be possible to deploy functional updates at a quicker pace than that for on-premise solutions, as well as taking into consideration that updates shouldn’t break customer specific configuration or functionality.
These elements, along with others, spills into the architecture – that needs to be more loosely coupled, utilizing a decoupled messaging strategic allowing to deploy functional instance clusters – by using a service oriented approach, like MSA – Micro Service Architecture, and utilizing patterns like, say, CQRS. For all applications there will always be a certain requirement for customer specific functionality or configuration, which in a super scalable solution shouldn’t be accomplished by code changes, but by providing facilities in the underlying platform for extending the solution by means of metadata, configuration, rules engines or built-in scripting capabilities. For the latter, it is imperative that such a construct can be isolated within its own cluster to avoid scripts to impact the base system.
Another element of rewriting is the functional capabilities of the solution going forward. When faced with the opportunity/challenge of a rewrite – it is equally important to reconsider/rethink the functionality both at the micro-level (features) and at the macro-level (solution). It is an opportunity to solve previously shortcomings as well as focus on new capabilities that may not even exist in current offering.
The above leads to the rule of rewrites: DON’T. If required, rethink and build new, with a sharp focus on the value creation a new solution would bring to the customer.
Focusing on constructing a flexible architecture and internal processes allowing for continuously deployment initially, will pave the way for the ability to provide functionality to customers earlier in the development phase, than can be accomplished in an on-premise model, as you control the update cycles – and are not at the mercy of the customer’s ability or willingness to deploy updates. Moreover, it is crucial to align platform and functional development activities such that visible progress can be made available to the stakeholders, infusing confidence that the project is on track. With regards to the latter, then having tangible deliverables throughout the development phase will increase the success of the project significantly, not only because stakeholders tends to get nervous without visible progress, but equally important you will be able to receive customer feedback on a continuously basis, allowing you to either adjust or enhance features quickly and redeploy for feasibility testing.
The net is, that a transition from a traditional on-premise solution to a cloud based solution – in most cases – will take equal time as it took to develop the solution you are trying to cloud enable. The question then becomes, how to calculate the original effort. It is not that straight forward to calculate the total effort in man month invested in building a solution over a multi-year time frame, but it is a good mental exercise trying to do so – as it will give you a better idea of the total scope. In most cases people get surprised about how long it actually took to build a solution.
The next element of the top-level estimation process is somewhat controversially, as it builds on research into programmer productivity by Boehm conducted in 1995. Boehm found that a programmer in a medium complex system, effectively, produces 900 lines of code per month (LOC/pm). Note that this number is an average over the lifetime of a system. Initially the number is higher; however, as the complexity of the system increases the LOC/pm decreases. The LOC/pm can be used as a sanity check against the total estimated time from above.
The third element of the top-level estimation is to create a team estimate, where the development team themselves gives a high-level estimate.
Having these numbers will allow you to get a rough idea on the total effort required, and some numbers on which you can base your reasoning when presenting the effort and investment required to stakeholders.
To illustrate I will use an examples from two previous projects.
The team had estimated a total effort of 324 man month. The estimated historical effort came to 900 man month. The LOC/pm gave 920 man month. In this particularly case the actual time ended up being 870 man month. Here the historical and LOC/pm matched very well, but the team estimate was 37% of the actual.
In another project the team estimate was 180 man month. Estimated historical effort came to 800 man month. LOC/pm gave 1300. Here the actual time was 1080 man month. In this situation the team estimate was 16% of the actual.
In both of the above cases, the hardest part was not to convince stakeholders about the effort required, but to get the development teams to accept the initial estimation based on a combination of historical effort and LOC/pm. Personally I find that intriguing as it illustrates that developers are inherently optimistic when it comes to estimation. Not only at the micro-level – implementing specific features – but also at the macro-level – top-level solution estimation.
As a software professional I keep being astonished what users accept and put up with, when it comes to faulty, buggy and unfathomable useless apps or systems. You download an app from an AppStore, or if you’re older than 20, you may even install it on your laptop/desktop. Either way, you start using it – and it works fine, or at least it seems to work fine. But for some incomprehensible reason your device “blows” up. And guess what? We simply shrug and reboot the whole thing – and what’s most astounding is that we don’t even complain.
If you think about it then it’s comparable to that you every day gets the milk out of the fridge for your cereal, but randomly the milk would explode. Wouldn’t that upset you?
The other day on my daily commute I was, as usual, reading the latest news on technology and other, to me, interesting areas, I ended up spending most of my commute reflecting on the subject of mobile apps supporting disconnected state instead of reading. Honestly, I was rather annoyed with the situation, as I really enjoy being able to read my news and emails while riding the train.
So what was difference this particularly morning, since I usually read news and emails while on the train? Well, the difference was that normally I’m on an InterCity train that offers free WIFI, however, on this day I got on an earlier train – the sprinter – which doesn’t have free WIFI. Meaning, that I had to rely on “standard” mobile connectivity, which can be sketchy, even in a country like the Netherlands that got exceptional good network coverage.
Being without reliable connectivity I started testing a number of different news reader apps like Zite, FlipBoard, Dr. Dobbs and others – and found that they all requires connectivity to function. None of the newsreaders I tried, offered any solution for reading news without having connectivity. Which is some part peculiar, and I would argue a major flaw. Most of the apps build personalized news based on users preferences, it’s not as they’re searching the net for news. They could easily, on launch, download the news the user are interested in and store it on the device, and whenever there’s connection sync with the server.
If you think about this, then most of these apps and any other app that relies on connectivity is simply a revamped web app, and they doesn’t really offer any noticeable better user experience than a mobile web app would do. So why even bother building these apps as native apps? Apart from be able to distribute them as native apps by means of the app stores. But honestly, these apps don’t provide any additional advantages over traditional web apps.
When building native apps for devices like the iPad it’s crucial that there are additional benefits for the user over building mobile web apps. And one of these additional benefits is the ability to design and create apps that are capable of running without connectivity – disconnected. Remember that the mobile devices got – nearly – all the capabilities of a modern laptop. Storage, file system and database, so there’s a lot of power of API available to facilitate a great user experience, even when the device is disconnected.
When building mobile apps, you should rethink the functionality in terms of being disconnected. Look at the use case you’re trying to solve, and then rethink the use case in the light of being disconnected. Ask yourself, what your users wants to be do if there’s no connection. In the example of reading news, then I would assume that my users would like to be capable of reading news regardless of whether or not there’s connectivity. Compare it with reading a newspaper, and provide similar functionality – since that’s what the newsreader is trying to substitute – the good old newspaper. For the current mainstream apps in the newsreader space, they clearly haven’t succeeded in providing that richer user experience.
And to everyone out there, arguing that there’s such thing as perpetual connectivity, I suggest you go on a road trip, using different means of transportation as that’ll make you understand that perpetual connectivity doesn’t exists.
Recently I’ve been following some interesting discussions on the subject whether to develop native apps for mobile or using cross platform technologies. Let me elaborate what I mean by native apps. A native app is an app that is built using the tooling provided by the vendor. So for iOS devices that would be Objective-C and cocoa touch, for Android and RIM that would be Java.
Mostly the discussions seems to be concentrating on two underlying subjects: 1) how to utilize existing skills and framework knowledge and 2) how to support multiple mobile platforms with one code base. You can argue that these two subjects are intertwined and cross platform solutions tries to solve both areas simultaneously. Which is somewhat correct; however, #2 actually got another level as well, as there’s a whole range of MEAP vendors trying to push “code free” solutions, requiring none or limited coding.
Let’s look at #1 and what seems to be the key driver behind wanting to use existing tooling or similar tooling and technologies. Well, should be obvious, mostly seems to stem from a wish either to save money or reuse skills. The former is primarily driven by organizations whereas the latter is developers wanting to develop apps, but don’t want to go through the hassle of learning and new set of tools and technologies (see my blog on this, choosing the right tools). Also, there’s the latest SDK problem. If you’re using native you’ll always have the latest and greatest SDKs at your disposal; whereas if your going with non-native you’ll have to wait until the vendor gets his version ready. The time the vendor uses to do that, your competitors that uses native SDKs exploit new features and leaves you behind.
#2 is a repeat of previous attempts to find a silver bullet for supporting a number of platforms, build-once-deploy-many. So far nobody have succeeded in this field, at least not that I’m aware of. Back in the early nineties a substantial number of companies tried to build CASE tooling in an attempt to abstract the development away from code and hence be able to design once deploy many. Nobody uses CASE tools today. There was also a number of attempt trying to build cross platforms for Wintel and Macintosh. None of these are around. Personally I wouldn’t hold my breath or bet my business on the MEAP vendors, they’ll be gone as soon as the mobile OS market starts congregating towards 2 maybe 3 platforms.
Another thing about MEAP is that in trying to target many platforms they end up having to go with the least common denominator. And frameworks typically gives you 80% of what you need, the last 20% you can’t do and have to go into native code anyway. And guess what, it’s the last 20% of finalizing the project that takes 80% of the time. So no real gain (only a lot of pain).
Another important and often forgotten subject is the user base of certain technologies. The more users using specific technologies the easier it is to get help, find solutions and sample code. With lesser user adoption you’ll be more left on your own and can only rely on the vendor, who will most likely charge you for anything and everything possible.
If you haven’t already guessed then my stand is native everything, you get better apps, they look cooler, they feel like native apps, you don’t risk having to wait for a vendor to implement latest and greatest features, you don’t risk a vendor suddenly going out of business, you got huge user communities that can help and you won’t end up being charged unreasonable amounts of money for simple questions.