Line of business (LOB) applications are typically characterized as the mission critical IT part of a company's business. This could be the ERP or the CRM software, the MES (Manufacturing Execution System) in a production company or the project management system in a construction company.
In other words - if the LOB app doesn't run, the company typically won't invoice, produce, plan or sell anything - and thus quite quickly lose a lot of money - or even come to a complete halt.
During the last decade we have seen more and more software solutions being programmed or re-programmed for the cloud. This exercise typically involves considerations like user interface (thin client), responsive design, latency, multi-tenancy, scale-out, database architecture, service orientation etc. Just to mention a few.
All topics which are core to the design of a software solution. Which is also why it is hard work for a SW vendor to get a traditional LOB app to run truly in the cloud. I don't necessarily buy the argument that since customers won't like their mission critical software to run in the cloud their LOB app is not yet there. Most often this argument is put forward by software vendors who at the same time have real difficulties transforming their 10-20 years old LOB application into a cloud solution. Simply because the LOB application was never designed with that in mind. In many cases, customers would even prefer their LOB app running in the cloud as long as it's doing what it is suppose to do and the performance and security is adequate.
The real obstacle for moving a LOB app to the cloud lies in the core of the design. If the LOB app is designed as a monolith, perhaps even with a proprietary thick client, and even worse - with a lot of business logic in the client - it's tough to reap the benefits of a true cloud solution - such as scaleability, sharing of resources (database storage, processing power, accessability etc). not to mention the most problematic aspect - that many standard LOB apps are customized by customers.
The customization aspect is in fact perhaps the greatest barrier for moving a LOB app to the cloud. Simply because the promise of the cloud is somewhat lost if each customer still needs a dedicated enviroment (= private cloud).
So what do vendors of LOB apps have to do. Well - in fact they have to rethink the customization story completely. This is what Salesforce has done and in a smaller scale danish vendor e-conomic is trying to do. Inventing a "simpler" or more structured customization model, where the core design of the LOB app is not really changed but instead "pluggable" and extendable through wisely designed interfaces.
I believe this is also what we will see popular ERP's such as Dynamics AX and Dynamics NAV move towards. Introducing an extension model which will replace the traditional customization model, where core business logic is modified per customer.
In conclusion, if you are to build a new LOB or are looking into redesigning an existing, you should probably think hard about which parts are truly required to be customized per customer and then concentrate on enabling an adequate extension or plug-in model to support those differencies. And then start designing/re-designing the rest of the LOB to take advantage of the true promise of the cloud with topics such as elastic computing, sharing of resources, multi-tenancy, one-click deployment - or in other words - remove the need for dealing with IT completely for the customer.
Thursday, June 25, 2015
Monday, June 1, 2015
What is your software development team spending time on?
Let's face it - many software development teams gets really annoyed when asked to register their time on a daily basis. But how do you know if they are working efficient if you don't know what they are spending time on? And - how do you know what they are spending time on if they are not registering it?
Ok, I get all the arguments against not doing time registration; "It's too cumbersome", "It takes too long", "Don't you trust me", "We've never done that and we're doing ok!"
I have been running development teams both with and without time registration and in general I agree that both approaches can work. But - it depends a lot on the situation.
The key point is that as a software development leader you need to know what your team is spending it's time on. And you need to find a good way to obtain this knowledge.
For smaller teams - and/or if you are doing part of the work yourself - it becomes easier since you can be very close to each individual in the team. If you have largers teams or multiple teams it gets a bit more complicated to understand the details of efficiency.
let's start taking a look at some of the things a software development team is usually spending time on,
Understanding how time is spent is a pre-requisite to understanding how to optimize. You will often find interesting correlations. As an example low customer satisfaction is often correlated to either low time consumption in the requirements, speficication and design phases (pre-release) or high time consumption in maintenance and support (post-release).
High complexitiy in the solution architecture can be accompanied by high time consumption in stabilization and the examples goes on and on.
If you have been tracking time spenditure for some time you will eventually be able to start optimizing the different aspects of software development and at the same time monitor whether the changes actually works as intended.
Planning future work also gets a lot easier if you gradually develop rules-of-thumbs for your team based on historic performance.
Ok, I get all the arguments against not doing time registration; "It's too cumbersome", "It takes too long", "Don't you trust me", "We've never done that and we're doing ok!"
I have been running development teams both with and without time registration and in general I agree that both approaches can work. But - it depends a lot on the situation.
The key point is that as a software development leader you need to know what your team is spending it's time on. And you need to find a good way to obtain this knowledge.
For smaller teams - and/or if you are doing part of the work yourself - it becomes easier since you can be very close to each individual in the team. If you have largers teams or multiple teams it gets a bit more complicated to understand the details of efficiency.
let's start taking a look at some of the things a software development team is usually spending time on,
- Administration
You don't necessarily want them to spend much time on this but it is unavoidable. You decide yourself what to categorize under administration, but some common activities can include vacation, sickness, department meetings, celebrations, education etc, career dialogs etc. Some of these you may want to detail out separately. - Product Development
This is where you want your team to spend their time. This category will typically include aspects like gathering requirements, writing spec's, design, coding, test, documentation, sprint planning, retrospectives, project management etc. All the things that are absolutely necessary in order to get the software done. If you are very specific you may want to drill down into the ratios between the different aspects... - Stabilization
Your team is writing the last bit of code before all features are finally complete for the next release. However, for many good reasons you need a bit of time to test and fix the last bugs before shipping. For some teams this becomes a never ending death march... - Maintenance and support
The version you have released to your customers may have flaws...they need to get fixed. Bugs are found, incidents are logged. In general time spent on this should be minized. Some teams have found they spend as much as half their time on fixing old stuff...not optimal. - Assisting others
So your team is incredible knowledgeable. In fact, sometimes they are the only ones who knows and can answer questions from others in your company. So they spend a lot of time on this. Time, which is taken from the time they could have developed the next version...
Understanding how time is spent is a pre-requisite to understanding how to optimize. You will often find interesting correlations. As an example low customer satisfaction is often correlated to either low time consumption in the requirements, speficication and design phases (pre-release) or high time consumption in maintenance and support (post-release).
High complexitiy in the solution architecture can be accompanied by high time consumption in stabilization and the examples goes on and on.
If you have been tracking time spenditure for some time you will eventually be able to start optimizing the different aspects of software development and at the same time monitor whether the changes actually works as intended.
Planning future work also gets a lot easier if you gradually develop rules-of-thumbs for your team based on historic performance.
Subscribe to:
Posts (Atom)