Strategies for Embracing Current and Future Technologies
Introduction
With so much emphasis given by the press and industry commentators on the new and the exciting, the possible and the future, it is sometimes easy to forget that the way forward will be built on the tried and tested, the here and now. Although over the last 25-30 years there has been much that has been considered revolutionary within IT infrastructures, there is far more that has been evolutionary. Evolution is the natural way forward, and when revolutionary comes under close scrutiny there is, in nearly every instance, a strong evolutionary element.
We no longer throw away technology, we re-use and re-purpose it. The costs involved in wholesale infrastructure change far outweigh any possible benefits. Part of the IT infrastructure that needs to evolve are the applications that exist as the heart of every organisation. These applications have already evolved over many years, and over their lifetimes have undergone many alterations.
One of the problems that exists with the applications that give the business life is they are becoming worn; they have been altered, patched up, made to fit purposes for which they were never intended. The time is now right to take stock of these applications to give them a chance to perform as they once did, as vital elements within the business infrastructure, not as badly purposed and poorly understood pieces of technology.
This Report will show why the time is now right for this stocktaking. The maturity of technologies that will allow for effective change in applications creates an opportunity to move forward in a decisive manner. The external influences that are putting organisations under increasing pressure have to be addressed. The response mechanism lies in the applications that run the business; business change means application change.
Business Issues
The old proverb 'timing is everything' might be hackneyed, but it still conveys an essential truth. In business, getting the timing wrong leaves organisations exposed. Try an implementation too early and the possibility or probability exists that the full value of emerging technologies will not be utilised. Implement too late and competitive advantage has been handed over.
With so many other matters pressing for attention, the argument for Application Modernisation has to commence with timing. One element of timing that has affected applications over the years is the point-in-time functionality that exists with application implementation. Applications are implemented with two constraints. The first of these is available technology. In the broadest sense this will encompass what any given application can achieve. For example, document storage and retrieval has undergone rapid improvements, applications implemented five years ago (state-of-the-art then) will now be seen as slow, ponderous, and unable to match the functionality of more modern applications.
The second constraint is the business need at time of implementation. Technology in general, and applications especially, were introduced to match a business strategy; to aid the business in cost-cutting or revenue generation based upon a strategic plan. A prime example of these would be early ERP or SCM systems. The supply chain model has undergone major change in the past several years, and those organisations that are tied to applications unable to respond to that change will be operating at a disadvantage.
It is worth noting for this last example that we are not talking about changes in technology, but in the way that business is perceived and carried out. External forces demand change within organisations, and the applications in place are not always best-suited in their present form to respond to those demands. The key here is the phrase `in their present form'. No-one would recommend a wholesale change of applications every time a new requirement arose or every time new technology became available. What is required is a method of ensuring that while the incumbent applications might not be considered `state-of-the-art', they can at least answer the majority of the issues raised by new models.
The counter-argument to this has always been that LOB or critical applications must not be touched, they are running the company and should be left strictly alone. Several years ago we were all affected by that attitude. The applications that were 'too important' to touch because of the 'if it isn't broken, don't fix it' attitude, were found to be broken. This breakage was not in the sense of any inability to work within new business models, but fatally broken in terms of Y2K.
Mention of Y2K is important from the aspect of what was discovered alongside the hunt for date-related code. This discovery was that very few people really understood what the code was doing. Very few organisations overcame the Y2K scare by going to documentation that pointed to the relevant sections of code.
This is a strong indication as to why the time is right to look again at the applications that are running the organisations. We have applications in control which are not understood. This has to raise the questions of how are these to be made to fit new business models when the inner workings are not fully understood, and how can business strategy change when the applications that control the business cannot?
A key business message in this Report concerns the wresting back of control from the applications; making them serve new purposes now and in the future. Whilst, hopefully, we will not have to go through another period similar to Y2K, nothing is certain, and a quick evaluation of the cost of fixing something that wasn't broken should be enough to exercise the mind towards studying the ROI of Application Modernisation.
Technology Issues
All the surveys carried out by Butler Group in recent months demonstrate that integration, security, and Web services are of primary concern to our readership. Insofar as Application Modernisation is low on the list of priorities, this Report may appear to be of little interest. However, a mere phrase should not be taken to indicate the totality or reach of a solution. Take for example the concerns so prevalent regarding integration. The easiest path to integration is by splitting integration and interoperability into two distinct areas. When it is discovered that many of the integration problems can be addressed by interoperability, much of the pain disappears.
The downside of this approach is that both integration and interoperability are difficult to achieve with procedural code bases. Componentisation is a proven and workable method of making both integration and interoperability easier to achieve. As componentisation is a central methodology to Application Modernisation, it follows that Application Modernisation is an effective precursor to integration.
As an extension to this, if integration is not to become an ongoing never-ending process, then componentisation has to take place. Carrying out straight integration into applications that do not comply with an object design paradigm will require decoupling and new integration when the application changes. Multi-tier application modelling overcomes some of these issues of change management, but in the final analysis true componentisation will need to take place in order for applications to become more agile in response to business change.
The familiarity that most professionals will have with wrappering techniques, primarily used in the past for Web-enabling applications, makes this approach the most comfortable. It is, however, limiting in the long term and a decision will have to be made at some point as to a cleaner form of componentisation to reduce complexities of management.
Many of the problems associated with creating a componentised world out of procedural code have been overcome with the increased functionality of automated tools and the increase in understanding of requirements in terms of creating components based on a three-tier model, comprising common services, business logic, and presentation. Application Modernisation also allows the introduction of modelling tools into the new design frameworks; giving access to UML functionality that more closely aligns business requirements with development techniques.
One of the major barriers (both perceived and real to a greater or lesser extent) has been the disjoin between the relational data storage model and the pervasive world of objects with encapsulated data. This disjoin still exists but the gap between the two is narrowing all the time. All the major vendors in the RDBMS space and many of the transformation vendors are working to market viable solutions, and these are already starting to appear.
Market Issues
The majority of enterprises can no longer ignore the need to operate more cost-effectively; we are all expected to do far more, with far less. In almost all cases this results in reduced budgets and scaling back on available resource, with the added imperative of ensuring that the resource that remains must operate at high levels of performance and reliability. In application terms, this is a driver to acquire the tools and/or expertise to dependably maintain enterprise applications that might have grown with the business over the course of years.
However, these systems do not lend themselves well to modernisation, or to integration with agile business strategies. Although core business applications often pose these difficulties, the dichotomy being faced is that while some form of change management will be required to ensure that they enable the organisation to innovate with new services, those applications are still the lifeblood of the business.
The financials sector is almost certainly the best example of an industry that is caught between equally demanding extremes - the need to operate in a thorough and audit-worthy manner, ensuring compliance to legislation, and also robust security, and at the opposite end of the scale, the demand to keep increasingly demanding customers satisfied through the rapid and flexible provision of new services and products.
Although financials provide excellent examples of market issues, the Application Modernisation market is a truly horizontal one, as every organisation that has become dependent upon long-established software and systems is faced by the same problems - the differences between industries are of degree, rather than of type.
Whether organisations like it or not, they are forced to acknowledge that core applications are still corporate assets, albeit ones that require some work to restore them to their former glory. It is also the case that the systems upon which these applications reside also have the potential to continue to add value to the business, which brings us to the issue of the mainframe. Butler Group believes that market recognition is once again growing that the mainframe is a significant enterprise asset, rather than a burden. Another important element in the gradual change in corporate thinking about the mainframe lies in the fact that it is a very cost-effective platform for running Linux - this is, of course, another reason why IBM is unlikely to neglect the mainframe side of its business.
These factors combine to present businesses with a clear requirement for integration between a variety of existing and contemporary applications and operational platforms, and in the short term at least this demand will be met by the implementation of Web services in connecting roles between the diverse elements of the organisational infrastructure. These additional layers will be used because the developmental costs and operational risks are low, and vendors providing support for their creation will prosper.
Long term, however, the only real solution to ageing enterprise systems will be modernisation and the use of invasive approaches and technologies. The future of this market lies with change management and the renewal of enterprise applications, as this is the only means by which they can truly be future-proofed.
Der vollständige Bericht kann bei der Butler Group bestellt werden.