| 1.1 Portfolio
03 Reusability Policy | |
|---|
| ITIL 1.1.01 Reusability Policy |
|---|
| 1.1.03 Reusability Policy: | | After a lifetime of promoting reusable components the world has changed and security is now dominant. In many cases, the most effective way to implement and prove that an application service is secure is to deliver a large number of very simple services, rather than a small number of reusable services. Continual improvements demand that each company is provided with their own unique application service that is changed as and when each company can absorb each improvement. Reusable application services could never have such a complex life cycle. |
| Client-Server: | | In the good old days of client-server software, costs could be reduced by programming reusable modules. A registry of parameters could then tune the generalized software to perform in different ways for different implementations. By definition, this policy will only work where each company has their own unique servers and software installation. | | The client-server era is over and cloud based application services enables many hundreds of companies to share the same infrastructure. When a change is applied for one company, it would be unreasonable to imagine that all companies would wan tthe same improvement at the same time. Reusable modules are not effective and are not secure - the era of reusable modules is over. | | Client-server software had a low rate of maintenance and as more companies shared the same software, the rate of maintenance reduced. It is not practical to provide continual improvements to each of hundreds of companies when reusable services have been built. |
| Security: | | Simplicity of a large number of small functions provides security in a modern world where security trumps all other design factors. It is now essential to be able to apply a rapid improvement for one company without impacting the method of working for all other companies. If any function or service was reusable, when and how could it be improved? | | Problem: | | In the good old days a Statement-of-Fact could be reusable by all companies with a bunch of registry parameters to vary how data was presented to each user role. From a security point of view, a criminal could hack the registry in such a way that a agent could view data that was reserved to be viewed only by an Owner. Reusability creates a vulnerability that can be attacked by criminals. | | Solution: | | Modern web services deliver totally unique services for each class of user. The Agent and the Owner each signs into their own private world of data that is not shared with any other class of user. By design, the services used by a Agent cannot be used by an Owner and vica versa. |
| Security: | | When an external security audit is undertaken, every opportunity must be taken to be able to prove by architectural design, then the application stack is inherently secure. While each function will need to be tested, where it can be shown that it is impossible for a Agent to use an Owner function and where a Agent-Manager service can only be used by a Agent-Manager, then this simplicity of design will have large rewards. | | Distinct application services are provided for each class of user in such a way that it is self evident to a security auditor that no registry parameters exist to be hacked as a potential vulnerability. The Statement-of-Fact service for the Borker is distinct and unique from the Statement-of-Fact service provided to the Owner. While some services may appear to be similar, from a security point of view, nothing can afford to be reusable. |
| Life Cycle: | | Reusability had it place in the days before security and privacy became such overwhelming design and operational factors. Today, it is hard to imagine where resuability cost savings would not be trumped by security business requirements - it is better to be secure in the long term than to save some initial development investments. | | It would be impossible to have reusable services and deliver continual improvements for many hundreds of different companies. The application services provided to each company have their own unique life cycle and change cycle. |
| Reusability: | | The purpose and benefit of reusable application services is that costs can be reduced and flexibility can be increased. This reusability policy was practical with client server software packages where "one-site-fits-all" packed software was sold to a modest number of companies. | | The cloud has opened up a new world with many hundreds of companies who have their own unique business requirements. It would be foolish to imagine for a moment that hundreds of companies could be productive, efficient and effective with the same application service. Further, when one company wishes to see an improvement in one area, it would be foolish to imagine that hundreds of companies could be ready to accept the same improvement at the same time. |
| Risk Analysis: | | It may be acceptable to provide a common service to a Cover-Holder User and a Cover-Holder Manager. The vulnerability and risk of hacking the parameters that differenciate between these user roles is not significant and so costs may be reduced with a parameter driven reusable service. | | This is very different from the risk of one Agent-Manager viewing the data that is owned by a different Agent-Manager. Very strong security precautions must be implemented to ensure that data cannot be hacked by one Agent-Manager from a different Agent-Manager. The solution is to avoid reusability and deliver both data and functional access control to different services. |
|
|