One of the main reasons to go to cloud is the ability to deliver value lowering the
infrastructure obstacles and costs.
An app can be easily delivered, shared and used by several clients all at the same time allowing to greatly reduce the time to market for new features or software.
Translated in business language this means a quicker return of the investment, tailored developments and more value for customers.
A company able to deliver software and services under those conditions is considered to be Agile. But is this adjective referable only to the software development process ? Is it enough ?
Of course being Agile on the software delivery is just the starting point. A truly Agile company adapts the business process around his customers needs. The sales process needs to be Agile, the business support needs to react Agile to process changes.
Ideally you want to be able to catch the needs of your client offering the right solution in the shorter possible time ... and worthless to say: reducing costs :-).
This can be a huge change of company mindset and will definitely involve a change on the customer side as well.
Depending on the nature of the business, the final users will have to be progressively involved from the definition of the requirements up to directly being engaged on the validation of the delivery.
To be able to put in place such change of strategy, you will have to reduce to the minimum formal requirement documents and tedious client specifications. The requirements collection will have to be more lean. The prototyping activity, that allows the customer to "touch" new features while are designed, should be preferable to a formal design. It became then obvious that typical Agile short life cycle development is useful to engage the customer with the validation of the solution proposed.
Despite what many people may think this business model is not only applicable to small companies. There are huge corporate who already adopt it. Even the customer engagement on the validation of the solutions can be done at large scale automatically collecting usage info (like in mobile or web apps).
The agility will free creativity. Software Architects will be challenged more and more to create new solution without being afraid, because the user feedback will be quick and detailed. They will not have to wait for a far release date and a consequent live production to evaluate the effectiveness of their choices.
We are going trough a sort of "natural selection" distinguishing between who still linked to old patterns/practices and who's exploring new "cloudy" worlds ... In technology the foster to innovation still the main evolutionary model despite the conservatory instinct for old "reassuring" practices ...
In my next posts I will start a dip dive into some of the emerging architectural pattern for the cloud ... stay tuned ...;-)
An app can be easily delivered, shared and used by several clients all at the same time allowing to greatly reduce the time to market for new features or software.
Translated in business language this means a quicker return of the investment, tailored developments and more value for customers.
A company able to deliver software and services under those conditions is considered to be Agile. But is this adjective referable only to the software development process ? Is it enough ?
Of course being Agile on the software delivery is just the starting point. A truly Agile company adapts the business process around his customers needs. The sales process needs to be Agile, the business support needs to react Agile to process changes.
Ideally you want to be able to catch the needs of your client offering the right solution in the shorter possible time ... and worthless to say: reducing costs :-).
This can be a huge change of company mindset and will definitely involve a change on the customer side as well.
Depending on the nature of the business, the final users will have to be progressively involved from the definition of the requirements up to directly being engaged on the validation of the delivery.
To be able to put in place such change of strategy, you will have to reduce to the minimum formal requirement documents and tedious client specifications. The requirements collection will have to be more lean. The prototyping activity, that allows the customer to "touch" new features while are designed, should be preferable to a formal design. It became then obvious that typical Agile short life cycle development is useful to engage the customer with the validation of the solution proposed.
Despite what many people may think this business model is not only applicable to small companies. There are huge corporate who already adopt it. Even the customer engagement on the validation of the solutions can be done at large scale automatically collecting usage info (like in mobile or web apps).
The agility will free creativity. Software Architects will be challenged more and more to create new solution without being afraid, because the user feedback will be quick and detailed. They will not have to wait for a far release date and a consequent live production to evaluate the effectiveness of their choices.
We are going trough a sort of "natural selection" distinguishing between who still linked to old patterns/practices and who's exploring new "cloudy" worlds ... In technology the foster to innovation still the main evolutionary model despite the conservatory instinct for old "reassuring" practices ...
In my next posts I will start a dip dive into some of the emerging architectural pattern for the cloud ... stay tuned ...;-)