AT#1: Regain Control – make Business People accountable for Architecture
Most IT landscapes of larger companies consist of hundreds of applications that are interconnected via poorly designed interfaces. In most companies, these IT landscapes already have an enormous technical debt (see Bob Martin’s Blog), i.e., an ‘unnecessary complexity’. In my experience, a company typically runs between 80% and 90% more IT applications (and therefore also servers, databases, networks, costs) compared to what would be needed if it had implemented the ideal architecture. A tremendous waste of money and resources, and the reason why IT is perceived as tardy and as a cost factor and not as an enabler.
The following figure shows schematically what typical application landscapes of medium to large companies today look like:
And there is one main reason for this disastrous situation:
According to Andrew Defrancesco, business units are not aware of its responsibility for their applications and do not think architecturally.
There is a tendency to blame the IT department for this situation, but that’s not true. It’s a business problem. Requirements are typically not consolidated well across departments. IT has always just been the contractor who had to implement those punctual requirements under time pressure.
Problems like
- Overlapping responsibilities between departments
- Unclear data- and process ownership
- Acting in departmental silos
- Weak links between processes that should be connected (like strategy, product management, process management, enterprise architecture)
- Thinking in the short term has priority over long-term sustainability goals
are the main reasons for the decaying application landscapes and are common to all organizations I know.
What you should do
- shift your focus from software- to business architecture
- use LARD-style (lines and rectangle diagrams), simple architecture maps that make problems like mentioned above transparent
- connect the disciplines from vision building to strategic planning to technology implementation by the relations of a lightweight model.
