Weekly Planning The practice of IT Strategy or IS Planning has been a top IS management issue over the years. It has spawned methodologies, consultancy practices, research and a veritable lexicon of terms. These include “IS Strategy Planning”, “IT Strategy”, “the Applications Development Portfolio” and “Systems Long Range Planning”. None of these ambitions is nonsensical. There was and is a need to align IT investments with the business; it helps to have a long range plan for IT resource development and deployment; there is often a need to prioritise application needs and requests; IT application development projects could be multi-year activities. So whether IS/IT planning was an annual, occasional, three yearly (or more) exercise, it was generally long term and involved substantial effort.

In e-commerce ventures, IT planning often is done through weekly, Monday meetings. In one 18 month-old dotcom start-up, the CEO and CTO meet weekly to agree priorities in order of urgent fixes, missed deadlines, reactive opportunities and next step business developments. This practice was explained thus: “The vision is constant but plans change and details drive tactics”. In a spin-off e-business, the management team reviews the project portfolio and new application ideas in terms of both priority and progress. A three month project would be long-term in this company whose new motto is “ruthless execution at speed”.

In an incumbent company with a separate “E-IT” department, the e-commerce ventures management team meet with the E-IT managers every Monday to review progress and review priorities. “We limit our portfolio to six projects but there are usually ten requests, so it’s all about prioritisation … Our IT plan is a project portfolio written on one page showing which projects are in scoping phase and which are active”. IT planning, then, has become short term and the plans are typically rolling ones. This new practice is perhaps analogous with rolling budgets, a procedure which also evolved in dynamic environments.

Three Tier Architectures “Architecture”, the conceptual design or framework for IT infrastructure development, is concerned with meeting objectives of systems integration, technology interoperability, platform reliability, application maintainability and IT cost management. It is perhaps easier to describe than implement, but in recent years the drive for a single “desk top” or common enterprise resource planning systems or global data standards in corporations has been evident. There has been a quest for uniform platforms.

However, when technologies are evolving rapidly and business change is endemic, architecture design and implementation are very difficult. Not only is there high technological`and business uncertainty, but in any but the most youthful e-commerce ventures, there is the need to connect and integrate short lived and volatile customer-facing applications to more enduring, perhaps old or even legacy, systems and to incorporate new, immature and perhaps rapidly obsolescing technologies. So the spirit of architecture becomes more like “mix and match”.

For example, one dotcom start-up talked of begging, borrowing and bargain basement buying of technologies which got them started, but soon were found to be non-scalable, unreliable or too complicated. However, they had to be replaced over time depending on business imperatives and affordability. Spin-offs often have to patch web-based front-end applications on top of inherited legacy transaction processing systems and then the search begins for how to both ensure reliability and provide adequate response times. Some application development boutiques did rapid builds of web-based consumer-facing systems and then contacted their clients’ IT departments later on to discuss how to connect their front-ends to quite differently constructed back-ends.

Terms we heard to describe these practices included “band aid”, “held together by chewing gum and string” and “patchwork quilts”. It seemed as though mix and match architectures were displacing the drive for uniform platforms. However, as our project unfolded, a new concept was evolving and dotcom start-ups and spin-offs especially were already embracing it. Three-tier or multi-tier architecture was taking over.

The central idea is that the volatility and perhaps rapid obsolescence of the front-end applications is recognised, but so too is the need for stable, robust, reliable back-end applications commonly the transaction processing systems and data warehouses. So (Fig.1), these two domains or tiers are recognised as different and are connected by a “middleware” or “technical wrapping” tier which translates data messages between the two layers, stores processing logic and data objects and provides a gateway between ephemeral systems and more permanent ones. This practice makes both business and technological sense.