The rules of behavior one follows in life depend on the context: there are people who don’t behave as a grownup at work. While it is obvious to everyone, it doesn’t seem to be clear to a few IT managers and CIOs whose organisations are undergoing significant growth. Leniency allowed in an IT infrastructure when organisations are relatively small cannot hold on when companies grow. While coupling of systems is a necessary expedient in small organisations, it is totally unacceptable in the large enterprise. And if rapid growth takes an IT infrastructure from nascent IT to a mature IT in a time too short for adaptation, the growing pains experienced by these IT managers may be quite painful. When an organisation is small, it typically starts off with a financial system and core business applications such as Inventory Control, Customer Sales or Material Management. While these could typically be run as separate applications, a growth-focused company will quickly require that the two aspects of business be integrated: the CEO will want to know at any one point what his financial situation is as opposed to his assets. The IT manager then scuffles in a panic and eventually comes up with an acceptable solution: by the very nature of the request the two independent apps now get to access each other’s databases with the right of update. The business data that needs to be coupled with the financial data is shipped to the financial system and placed in newly created tables. The fact that duplication of information takes form is swept under the carpet. Soon, on top of regular event-driven feeds from the business system, the financial system begins to allow itself to fetch data directly from the core business system to suit its reporting requirements: unquestionably the essence of a tightly-coupled IT infrastructure. Why is an application allowed to play around with its own data, and not data from another application? It basically boils down to data ownership and responsibility. When applications begin to tamper with each other’s data, then the lines of responsibility begin to blur; except if the teams developing one application are very close or the same as those developing the other, which is typically the case in a small organisation. As an organisation begins to grow, other factors come into play: Its number of employees increases and their productivity becomes imperative; competition begins to drive increased customer-facing services; and a Web presence with stringent availability constraints becomes imperative; and so on. Within the IT infrastructure, new applications begin to proliferate and legacy applications begin to grow. Development teams begin to mushroom here and there. All of a sudden the question of data quality and ownership arises: who owns the customer data? The financial system or the core business system? Or both? Or neither? The question of system availability becomes crucial and applications are now assigned owners that have to answer to the CIO but because of rapid growth, the systems are very tightly coupled and when a problem occurs the blame business inevitably begins. A well informed CIO will look ahead and realise that there are ways in which applications can integrate without having to directly access and update each other’s data. As such, the concept of loose coupling begins to make sense to small organisations, and the drivers behind service orientation and asynchronous messaging become clearer.