|
Over the last forty years, software design and development have had many evolutionary steps but no revolutions, until now. In that time we’ve witnessed, or driven many changes. For example from structured, procedural coding to object orientation, from server-only UI to client-server and the introduction of thin-clients and application servers, from flat files to RDBMS and OODBs. In the world of integration we’ve seen lots of change over the years including transaction management systems, EAI and xml. But without exception, these developments have all been step changes, fundamentally we’ve not changed the way we design and develop software systems. Back in the bad-old days we used to define scope in terms of function. As the designer built lower level detailed functional models, the data required to support the function was identified. By the end of the 70s, or certainly by the mid 80s, most designers had changed around and either developed their data models first or at least as an equal partner to the functional model. Today we’re still generally doing exactly the same. This mind set works on the premise that we have a fixed scope of function and data interest and that in order to deliver complete end-to-end architectures, someone else can have the trouble of integrating. Of course in some industries, such as defence, designers often have the luxury of having an end-to-end scope but for most of us in the commercial world, and especially those of us building commercial of the shelf (COTS) products we have no idea of the final completed architecture. I believe that the concept of software we all have in our heads is: a set of functions with an associated local data store and with APIs provided to integrate with other systems. End-to-end architectures are built from islands of function and data (usually centred on an RDBMS or OO data store) which are integrated by a lucky designer. So why should we change this way of thinking, of building island applications. After all there is a cart full of technology to help integrators link systems together. What is the problem with continuing to build new function around a local database? Well, its clear to most large organisations that they’ve got enough - or rather too many - databases. Across many industries the direction is to reduce cost and increase agility and this requires reducing the number of databases in the enterprise (or corporate) architecture. This is where the first software development revolution that I’ve witnessed comes in and it is remarkably simple: All the data that you need already exists and is in an application that is accessible to you as a designer. We must stop developing systems around a separate new database and start to build applications that use the existing assets of the enterprise that your system will be working in. Of course its not so simple, otherwise we’d have had this idea before (and made it work). Some of the problems that face us are: the performance and scalability of APIs to get the data, the vast variation of data schemas and structures that hold the data and the management of data state. However there are tools available to you that resolve most of these problems. There are a growing number of revolutionary companies building conceptually-new software based upon this simple but radical shift of design. The old king has not yet been overthrown but the revolution has started and is gaining momentum. So throw away your concept of a system design, start using the data assets that already exist and join the revolution. Author: Paul Hollingsworth is Director of Product Marketing at Celona Technologies, a radical software company in the product portfolio management arena. The Celona solution seamlessly integrates with current legacy systems and utilises existing infrastructures, providing operators with the flexibility to make any additions and changes to their products and services as business prerogatives evolve without having to reconfigure the architecture in multiple places in multiple ways. www.celona.com Contact: Thor Windham-Wright Paul
Hollingsworth DISCLAIMER The views and opinions expressed in this article do not necessarily represent the views of MobileIN.com. You are encouraged to seek the advice of health professional concerning these matters of great importance.
|
|
