Français
A 'long and complicated handling', 'costly skills and expertise', 'sorcerer's apprentice architects', a 'stunning technology ecosystem'. The finding of CIOs on using the Java language is often no appeal, so that they may regret their good old languages, perhaps out-of-date in some domains but much more productive. Some companies are experimenting with more recent languages that promise to turn to overcome the shortcomings and the complexity of the Java language. Others seek to overcome definitively the source code by exploring new paradigms such as the modeling approach (MDA) or functional programming dedicated (DSL). But these practices are not yet mature enough to be industrialized on strategic projects. Another way is to build up on Open Source frameworks offering answers to the most common problems in application development management, provided to avoid some pitfalls.
Manage the proliferation of open source
Common sense tells us to build on already proven solutions rather than 'reinventing the wheel'. Thus, the CIO has chosen to make their own 'home framework' for obvious reasons of costs of maintenance and sustainability of their investments. This is even more natural that the Internet is full of components (or frameworks) to respond virtually all needs for a business application. They are themselves often distributed as an Open Source license guaranteeing freedom of use at lower costs for businesses.
But to find happiness in this burgeoning technology is also a real challenge. Indeed, nothing about major open source forges, not less than 1,500 technical frameworks Java, more or less mature, are competing to grow their communities of users, the buzz is one of the main criteria for selecting an Open Source component.This number rises to more than 20,000 components if you widen your search to specific functional modules.
As a CIO, you'll be faced with the choice. Once the selected components, you must then organize their interactions in the form of an assembly technique in managing the heterogeneity of programming interfaces. With the help of one or more technical experts, you need to build a development framework as a basis consistent with the majority of your applications to avoid duplicating the selection and integration work at the start of each project.
To achieve a base application of industrial quality (ie supplemented by code generators, a methodological approach and a structured process of development), it is reasonable to predict a phase lasting from 3 to 18 months of technical development with a team of 3 to 10 experts to your needs: level of integration into your information system, ease of handling by your developers, productivity and quality expected for the realization of your projects, criticality applications for your company...
It seems likely however that the needs identified for your CIOs are largely identical to those of other undertakings (connecting to a database, transaction management, access security, performance monitoring ...). So if you have neither the time nor the budget to build your custom application base, you can refer to a base application provided turn-key which can then be adapted to the specific context of your projects.There are already some open source application bases to ensure their empowerment and their mastery of your technical teams. Those bases are in the form of a distribution of open source components in an integrated application architecture covering an area more or less depending on the applications concerned. But beware, if you do not want your developers spend their time to visit forums no guarantee of success make you professional support on all of the base application to secure the implementation, maintenance and exploitation your most critical applications. Shared between companies using the common application base will remain cheaper than maintaining a home framework.
Absorb the components volatility
In recent years the home frameworks have been built by integrating the most recognized components, either relying on an internal team of architects, or by delegating this work to a provider. Once the technical base completed and delivered, this raises the question of maintenance for 5, 10 or 15 years (the duration of your enterprise applications).
The peculiarity of the Open Source ecosystem is that it is constantly evolving. It is also one of its greatest strengths because they are evolving, the components become more relevant and robust. This ecosystem is also regularly updated with new components more efficient or more innovative. Moreover, many recent innovations are derived from open source projects. However, poorly managed, the consequences of this versatile demographic may also be disastrous for your information system as the rythm of these developments is unpredictable and different for each component of your home framework. A particular component may also be deserted by his community but remain accessible on the Internet. The slightest mistake criticism becomes a kind of bomb for your applications. You will be sentenced either to replace this component with another newest minimizing the impact on your assets, or to assure yourself the maintenance of this component is now obsolete. Note that you can undergo this same type of discomfort following a technological breakthrough made by a major change, or by the sudden change of an Open Source license to a proprietary license.
The only way to anticipate these risks is to provide a technology watch by one or more experts on forums, blogs and other community sites. This ability to anticipate not providing yet to conduct replacement operations in due course.
It is clear that these monitoring activities and maintenance of the home framework are not a neutral budget. These costs are even more evil experienced by the enterprise organization they are misunderstood in their technical nature and unrelated to the business and functional enhancements expected by the company.
These costs finally induced harm the image of open source, often wrongly regarded as entirely free resource.
Survive to its architect
But basically what is a technical application framework? It is primarily a blend of technical components fit proposing the implementation of applications while taking into account the specific environment of each company. To best meet the demands and constraints of infrastructure and existing legacy applications, this construction requires the expertise of an architect with several years of experience in designing applications using Java and Open Source components.
However, the architecture phase represents only a necessary step in the implementation of one or several projects, the architect is often a provider of top-flight player in a limited time. Indeed, once the application base is stabilized, the role of the architect is not as critical. That is probably why the companies that have recruited their own architects often struggle to retain them over time.
Indeed, good architects draw their motivation in solving new challenges to improve their technical expertise. Maintenance phases rapidly induce the feeling of "vegetate", hence perhaps the reputation of "Diva" is often attributed to them.
Anyway, the departure of the architect of the base application is often synonymous with losing control of the base. This loss of control can quickly lead to difficulties or additional costs of maintenance, or even lead to the withdrawal of your technical partners who will not work on a obsolete or unsupported platform.
However, these pitfalls can be avoided by arranging a transfer of skills into a contract for operational maintenance application of your foundation over time or by choosing a shared application base supported the maintenance of which is pooled.
Exploit the wealth, remove the complexity
The subtleties of the Java language make it difficult to access for developers. This is even more pronounced for developers experienced in other languages often put off by the verbosity of a very structuring language. Paradoxically, this is the verbosity that ensures the quality and portability of applications developed in Java.
In addition, the integration of many open source components for the projects drastically increases the skills required for developers, and with them the difficulties of recruitment and budgets.
For many companies, the situation becomes complex when they must choose between his train to Java developers controlling the internal business of the company and the oldest languages, or outsource the development and maintenance of strategic projects with a provider.
Yet there are solutions to remove the complexity of language and its environment. Specific developments in Java can be industrialized by framing structural development methods and the use of Frameworks. You can rely on a continuous integration strategy for qualitative monitoring of the progress of your projects, or use an agile approach to project management, encouraging exchange of information and limit your dependence on key persons of the project while increasing your flexibility. Finally you can use at least a portion of source code generation tools and automatic testing partners.
To assist in this process of industrialization, some shared application bases go well beyond mere distribution of open source components and complement them with an overlay platform simplifying the coding of applications, code generators and a methodological approach. They offer the qualities of a traditional publisher model while leveraging the benefits of the wealth of Open Source.
Conclusion
The complexity of the Java world is real but its qualities, its openness and standardization push for its adoption despite the difficulties in building and maintaining its technological environment.
To take advantage of this environment, particularly well suited to information technology, it is essential to capitalize on the expertise and lessons learned from open source components that populate it. Beyond the economics of scale induced by the communautary approach, it allows you to benefit from evolving guarantee of reliability, interoperability and compliance with latest standards.
One of the biggest barriers to adoption of a strategy based on using open source components for a CIO is the abundance and versatility of the proposed solutions. Like Linux deployed as packaged solutions for businesses and supported (such as RedHat and Ubuntu) and Java application bases integrating operational distribution of open source components are beginning to make themselves known. For CIOs, industrialization and homogenization of their Java developments will likely build on this type of solutions that ensure the sustainability of their development work and savings by the pooling of support and maintenance work.
The emergence of open source vendors in this domain is an encouraging sign of maturity and application bases an appropriate response to CIOs who want to invest on their core business rather than technology that underpins them.
