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:
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.
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.
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:
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.
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.
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.
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”
Subscribe to our blog
Did you like this blog post? Never miss an update when we publish next:
ENTERPRISE DESIGN PATTERNS
Capturing a wealth of experience from many sources, four world-class enterprise designers and architects present a collection of 35 immediately applicable solutions to successful enterprise design.Buy the book