Sometimes, when I try to visualize data flows within an IT landscape I end up with something that has a surprising similarity with the cabling often found under desks of IT professionals. In both cases you might end up asking yourself:
»How could you end up with something as messy as this?« Before I try to answer this question let me give you a little tale based on a true story.
How things ended up
Assume its the late 90ies or early 2000s and you want to automate the creation of a printed corporate phone book. What would you do, if you are responsible for the company's ERP system and you have all necessary data except phone numbers which are only stored within the company's PBX system?
Back then the natural choice was to write a small script that regularly generates a CSV-file from the data stored in the PBX system and another script which imports said file into the ERP system. All this didn't require a lot of effort and a secretary in the company got more time for other, hopefully more meaningful, tasks. Now assume it is one year later and someone in the sales department needed all key account manager's phone numbers in their CRM software. The easiest thing was to copy the scripts used for the ERP-import and adjust them for the task at hand.
A year or two have passed by and printed phone books are totally out. The manager responsible for the shiny new corporate intranet wanted to replace it with an online variant. He asked the manager responsible for the business telephony system and they agreed to simply re-use the scripts already available given that this would require the least effort.
In the same year the IT department responsible for the email service replaced the existing mail system with Microsoft Exchange and as a requirement the old Windows NT domain was migrated to Active Directory. Given the tight budget and time constraints the directory was only used for the mail system and client logins.
A few months after the launch the admin managing the mail system wanted to write a script for automated mail signature generation and needed the phone numbers for that. Therefore a script was written that regularly imports the phone numbers into the directory.
Almost a decade passes by, some of the systems have been replaced or renewed, but the data architecture is basically the same. With many employees having a corporate mobile phone and the rise of BYOD the manager for the intranet is asked to give employees the possibility to add their private phone number to the corporate phone book. Luckily the newly established mobile device management software already has the numbers. The only thing required is an import script and an opt-in checkbox for the employee within the intranet. Therefore the manager accepts the request.
How things should ended up
 |
| Target Architecture in Theory |
Obviously, the realized data architecture in this example is far away from anything that would have been derived from modern standards. In addition the question might arise why one particular solution was never implemented given that it almost suggests itself. Best practice would dictate that all applications in need simply retrieve the required number from the directory. A simple, clean and extendable solution. This could have been implemented a long time ago, but nobody did.
Architecture management and the LEA-Principle
 |
| Effect of the LEA-Principle |
How cloud something like this happen? The answer is simple. Without dedicated architecture management nobody had a look at the big picture. Whenever a change is needed the responsible person implements it as fast as possible and with the least effort required to achieve the goal. Given that many companies apply change in form of projects, I like to call the resulting architecture management style least effort or project driven architecture (LEA or PDA) management.
So, in summary, the LEA-principle dictates that if you have no one responsible for architectural house keeping you inevitably end up with something similar like knotted cables under the desk.
/jr
