Blog

AT#10: Technical Debt – the ignored Killer of “Agile” Enterprises

AT#10: Technical Debt – the ignored Killer of “Agile” Enterprises

Trapped in the vortex of digital transformation, almost all industries are facing challenges caused by highly accelerated technology innovation cycles, new and disrupting competitors, and, last but not least, a tremendous amount of technical debt in their vast historically grown IT landscape.

Dave Sag’s blog provides a good summary of what technical debt means.

To deal with this area of tension companies trust in ‘Agile’ gurus that tell them how they must change their organization and culture to become ‘agile’. If we look at the complexity of the application landscape of a typical company it becomes obvious that they simply can’t be agile without renovation projects that make their legacy IT agile.

What you should do:

  • Reduce your technical debt step by step by the renovation of your legacy IT. Agile IT landscapes make companies agile, not agile coaches that focus on culture and organizational aspects.
  • Hire business architects instead of agile coaches.

Previous Posts:

Launch of the Architectural Thinking Framework®

AT#9: Three Values that make your Enterprise Architecture Management successful

AT#9: Three Values that make your Enterprise Architecture Management successful

For sure, Enterprise Architecture Management (EAM) is still a very immature, weakly defined field. Most of the methods, tools, and frameworks suit the requirements of real-world projects only to a small degree. Most of the elements EAM tries to structure and manage towards a to-be state’ are abstract and hard to grasp. Archimate®, a modeling notation for EAM, for example, defines more than thirty elements, most of them are vague abstractions and far from tangible. In practice, EAM is much more focused on designing application landscapes than providing a holistic view of the enterprise. EAM is still very much about ‘application portfolio management’ that tries to minimize IT costs without alignment to the business capabilities.

But how can this sad situation be changed?

Our suggestion is to apply three values to your EAM practice: Read More

AT#8: Agile goes awry when loosing Balance between Speed and Sustainability

AT#8: Agile goes awry when loosing Balance between Speed and Sustainability

When Agile software development was born in 2001, it defined a set of four principles:

  1. Individuals and interactions over processes and tools
  2. Working software over comprehensive documentation
  3. Customer collaboration over contract negotiation
  4. Responding to change over following a plan

I have worked in several Agile teams where ‘responding to change over following a plan,’ often got misinterpreted to mean “don’t have a plan.”  Those teams often find they waste time by adapting too much.

Read More

AT#7: Collaborate! Or: beware of Ivory Tower Architects!

AT#7: Collaborate! Or: beware of Ivory Tower Architects!

Enterprise Architecture has a long tradition of mighty architectural gurus drawing fancy diagrams that never reach the reality of solution development.

In his article on the ‘Agile Modeling’ approach, Scott Ambler states:

‘An ivory tower architecture is one that is often developed by an architect or architectural team in relative isolation to the day-to-day development activities of your project team(s).The mighty architectural guru(s) go off and develop one or more models describing the architecture that the minions on your team is to build to for the architect(s) know best. Ivory tower architectures are often beautiful things, usually well-documented with lots of fancy diagrams and wonderful vision statements proclaiming them to be your salvation. Read More

AT#6: Enterprise Architecture is not TOGAF

AT#6: Enterprise Architecture is not TOGAF

Today I want to point to an article of Svyatoslav Kotusev, an independent researcher, who questions whether the Open Group Architecture Framework® (TOGAF®) is the industry standard framework that enterprise architects really deserve.

https://www.bcs.org/content/conWebDoc/55547

In light of these findings the growing popularity of TOGAF® can hardly be attributed to the real usefulness of its advice, but rather to a lack of any better alternative sources on EA.

The Architectural Thinking Framework® wants to become an alternative, open source on EA that is based on the real-world experience of many practitioners.

Read More

AT#5: Architectural Thinking – the iPhone of Enterprise Architecture Management

AT#5: Architectural Thinking – the iPhone of Enterprise Architecture Management

Typical deliverables and methods of current Enterprise Architecture Management (EAM) practices are overwhelmingly complex. EAM tools often include hundreds of out-of-the-box diagrams. The two most common architectural meta-models provided by The Open Group® (ArchiMate®, TOGAF® Content Metamodel) are voluminous and consist of 30+ artifacts and 100+ potential relations between artifacts. Those meta-models are based on sophisticated meta-meta models but have severe issues with clarity. To illustrate this, let’s compare the way an application can be modeled with ArchiMate® with the artifact ‘Application’ of the Architectural Thinking Framework:

Read More

AT#3: Design Thinking is cool! Architectural Thinking makes it amazingly cool!

AT#3: Design Thinking is cool! Architectural Thinking makes it amazingly cool!

Companies are in an uncomfortable position today. On the one hand, the digital transformation is forcing them to innovate at an increasing pace. On the other side, they run on a historically grown legacy IT and huge technical debt. The past is cemented into the vast existing application landscape, but the future requires a rapid transformation. For this reason, innovation methods such as “Design Thinking” and the ideas of the agile organization have gained massive popularity in recent years. It is hard to find a larger company that does not run an ‘Open Innovation Space’ where people innovate and build prototypes, and that is a good thing in principle. The only problem is, however, that companies usually do not steer their innovation initiatives towards a big picture.

Read More

AT#2: Demystifying Enterprise Architecture

AT#2: Demystifying Enterprise Architecture

Enterprise Architecture is still a mystical discipline, ruled by vague frameworks, surrounded by the fog of bloated concepts providing only little practical advice.

Let’s hand over to our friend, Nemanja Kostic who provides a humorous overview about the state of the practice. He makes suggestions that discuss how to demystify Enterprise Architecture,. This suggestions are quite compatible with our vision of Architectural Thinking.

http://www.entarchs.com/blog/demystifying-enterprise-architecture.html

 

What you should do:

  • heavily downsize the architecture meta-model. Focus your models and maps on value streams, capabilities, business objects, applications, technology components. It is enough to build a great! enterprise architecture practice.
  • build a lean but strict governance that welcomes the architecture work of many members of solution teams.
  • get out of the ivory tower. Sell the idea and significance of architecture to your agile teams and to business people.

AT#1: Regain Control – make Business People accountable for Architecture

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:

 

Read More