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 (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. From my point of view, there are three major reasons for this disastrous situation:

Business Units are not aware of their 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.

Unlike technical engineers, students of business schools do not learn to think in architectural structures, modules, elements, and their relations. Business architecture is not on the curriculum of studies like business administration.

No or poorly anchored Architecture Management

Enterprise Architecture Management (EAM) as an independent discipline has been around for twenty years now. However, the success and acceptance of this discipline are minimal for the following reasons:

• Existing EAM frameworks are too complicated, impractical and offer only a few how-tos that can be used instantly by newcomers.
• Most enterprise architects emerge from technical disciplines such as software architecture. They quite often underestimate the importance of business architecture.
• A small community runs EAM, often still inside the famous ivory tower. EAM is not widely known and accepted in the business community.
• EAM is still centralized, planning-oriented and driven top-down by a few and not recognized in the realm of autonomous agile teams.
• Many EAM approaches focus on managing artifacts, often limited to applications and technologies. Proactive innovating management has rarely been the job of EAM teams.
• As a result, Enterprise Architects are often seen as policemen, enforcing technology-heavy architectural guidelines rather than playing an active role in business innovation.

Time Pressure

Business Analysts and software developers often have to compromise on their designs because of hard milestones. Sloppy integration of new solution in existing applications is the rule, not the exception. Every unclean interface design, however, further increases the company’s technical debt.

Use the following three Steps to regain Control over your IT Landscape*:

1. Make Business People accountable for Architecture

Bad business decisions are the reason for the dramatic IT situation of most companies. Make business people accountable for these decisions and enable them to make the right decisions by teaching them to think architecturally using the following steps:

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.

2. Add ‘Technical Debt’ as a project metric

Today, projects are started based on more or less solid business cases. Two metrics are typically in use: cost and benefit. If benefit > cost – let’s do the project! Long-term, sustainability thinking is almost absent in today’s organizations. For that reason it comes to no surprise that technical debt got out of control in almost any larger organization. If you apply the famous quote ‘you can’t control what you don’t measure’ it quickly becomes clear that you need to introduce ‘technical debt’ as a third metric.

3. Integrate Legacy Renovation with your Governance Structures

The book ‘Managed Evolution: A Strategy for Very Large Information Systems’ (Murer, Bonati 2010) presents a strategy to manage the evolution of your IT in the direction of a stepwise reduction of complexity. It integrates legacy renovation deeply with the governance structures of the organization. In this approach each project is scoped in a way that brings the overall IT landscape closer to a better (i.e. less complexity, better modularization, lower maintenance cost) target state.

* The steps presented in this article are an integral part of our “Architectural Thinking Framework”