Archives February 2019

AT#29: Soft Factors of Architecture – Part 1: Trust

AT#29: Soft Factors of Architecture – Part 1: Trust

The stake of Business- and Enteprise Architecture is to ensure that the overall IT landscape and its solutions stay maintainable instead of increasing complexity with each project. Architects, usually without formal authority over other persons working in the projects, have to find soft ways to drive their stake,  and this is always the hardest part of the job. 

“In Enterprise Architecture roles, emotional intelligence (EQ) accounts for more than 90% of a person’s performance and success.”
[Gartner Group]

I have been working in the field of Enterprise Architecture (EA) for almost 12 years now. Over these years I have seen many unsuccessful EA initiatives. Half of the large IT transformation projects I worked in failed to a large degree due to insufficient influence of the architecture team. EAs often simply did not have the “right”social/soft skills.

Motivated by this observation I want to start a series of posts that deal with the “soft factors” of architecture, which are IMHO way more relevant than the analytical/technical bias prevalent in the field of EA. Today’s part 1 explains why building trust should be prio 1 for EAs.

Read More

Three Steps to Regain Control over your IT Landscape

Three Steps to Regain Control over your IT Landscape

Most IT landscapes of larger companies consist of hundreds of applications that are interconnected via poorly designed interfaces.To get well designed landscape you can click this link now. 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. Read More

AT#27: Capability Modeling Crash Course – Elicitation Recipe

AT#27: Capability Modeling Crash Course – Elicitation Recipe

If you want to learn more about capability modeling – register for the ->capability webinar we do approx. once a month.

Last week we completed our three-post crash course. We received lots of feedback and questions about how to elicit capabilities with the business people. The blog series reached an audience of thousands of people. For that reason, we decided to add a fourth – “da capo” post.

The previous post in this blog-series discussed why capabilities are the invaluable core of Architectural Thinking, how to use your existing process- or value stream maps and how to structure capabilities. Today we present how capabilities should be elicited by the business architect by a broad participation of business stakekholders.  Enjoy!

Read More