Blog

AT#62: Organisation Design and Enterprise Architecture – Putting People in Boxes???

AT#62: Organisation Design and Enterprise Architecture – Putting People in Boxes???

Enterprise Architecture (EA) claims to architect whole enterprises. No one can doubt that people are a vital part of enterprises – but can we put people into boxes???

Today we present a blog post by Intersection Group’s invited advising member Naomi Stanford that introduces organisation design. We at Intersection Group are working hard to bridge the concepts of organisation design with those of EA, so stay tuned!

———————————————– Read More

AT#61-Enterprise Architecture: Forget Systems Thinking, Improve Communication

AT#61-Enterprise Architecture: Forget Systems Thinking, Improve Communication

In mainstream literature, the very concept of enterprise architecture was always strongly associated, if not equated, with systems thinking. The reasons for this linkage are rather evident: modern enterprises represent complex socio-technical systems consisting of numerous interrelated business and IT components, or hierarchical systems of systems. ‘Enterprise architects often make a big deal about an enterprise being a system of systems, but, really, everything that we as enterprise architects are likely to think of as a system is likely to be a system of systems’, explained the late Len Fehskens, the chief editor of the Journal of Enterprise Architecture1 (page 12).

Systems thinking calls for attending to things in a holistic way, understanding mutual dependencies between various system elements and uncovering existing feedback loops in their dynamic behaviour. Unsurprisingly, systems thinking is praised by many EA gurus and academics. Some people claim that systems thinking ‘can be considered a basic principle of EA’2 (page 7), while others go even further and argue that ‘enterprise architecture is a way of using system thinking as an instrument to integrate and align all organisational levels’3 (page 5). It would be arguably fair to say that today, systems thinking represents one of the core paradigms occupying the mindset of EA practitioners, if not the single most prominent paradigm. And yet, is systems thinking actually so helpful for architects and EA practices?

Minor problem with systems thinking

Read More

AT#60-Constructing Digital for Deconstruction

AT#60-Constructing Digital for Deconstruction

“The information revolution is sweeping through our economy.  No company can escape its effects.  Dramatic reductions in the cost of obtaining, processing, and transmitting information are changing the way we do business.”

 

How do you relate to the statements above?  True? False?  Haunting you day and night?  Excited about endless opportunities?    Need help?  All of the above?

Here’s the interesting detail: it comes from a landmark article from Porter & Millar published in July 1985.  Yes, nineteen-eighty-five.  How old were you that year?  That’s 35 years ago!

Don’t re-read the quote to try to find a flaw related to its age.  There isn’t. Read More

December’s Architectural Thinking Wednesday Webinars

December’s Architectural Thinking Wednesday Webinars

We are proud to announce the beginning of a new series of ->free live webinars dedicated to all of our friends in eastern Asia, Australia and New Zealand (and elsewhere, too, of course!)

Every Wednesday 9am CET held 100% live and free by one of our members.

Topics covered in Dezember:

Stay tuned at: https://architectural-thinking.com/events/

 

AT#23: Use Your Wisdom to Make Existing Practices Agile

AT#23: Use Your Wisdom to Make Existing Practices Agile

Whenever I discuss with people from the Agile world what ‘Agile’ is all about, they tell me that it’s very core is a mindset that is established through values and principles.

All agile practices, methods, and frameworks evolve out of this mindset. Ahmed Sidky visualizes this idea in his ->webinar:

 

 

When I saw this picture my gut told me that there is something fundamentally wrong with this idea. It took me weeks to find out why: Read More

AT#42: Enterprise Architects are Dead. Long Lives Enterprise Architecture Management!

AT#42: Enterprise Architects are Dead. Long Lives Enterprise Architecture Management!

Since it’s beginning as a discipline, Enterprise Architecture Management (EAM) has been performed by a specific “Enterprise Architect” (EA) role. In practice, this role has been far too often reduced to managing the repository of IT applications and drawing fancy, IT-focused diagrams that never reach the reality of solution development. EAM, even after almost four decades, still seems locked in its ivory IT tower with only limited practical influence on strategic business decisions. How many enterprises have been actually architected by EAs?

But why? How comes that EAM fails to do what it is supposed to – architecting enterprises? My answer: Read More

AT#56: Enterprise Architects – Broaden Your Field of Vision

AT#56: Enterprise Architects – Broaden Your Field of Vision

…..

Intersection.group is coming. This blog post explains why.

…..

The typical career of enterprise architects (EAs) starts with IT-related studies. EAs then move from software engineering to software architecture and finally to EA. As a logical consequence, EA is still driven by an engineering mindset even if some EAs have moved to the field of business architecture. You can feel the rational, analytical approach to design enterprises in almost any diagram or map created by EAs – quite often ugly but precise. Read More

Upcoming Events

Upcoming Events

A lot will be happening in the upcoming weeks (see also our ->events page).

We will continue our well-received series of “Wednesday Weekly Webinars” with Annika Klyver’s talk about her Milky Way enterprise maps and further Architectural Thinking topics.

November will be a hot month for us:

  • It starts with a ->surprise on November 5th that unveils some exciting news
  • Architectural Thinking will be very present at this year’s ->Intersection conference, so register to listen to world-class keynotes and the latest developments on Enterprise Design and Architectural Thinking.
  • We are very proud that our ->book will be launched on Nov 18th

 

So – stay tuned and visit our ->events page every now and then!

Wolfgang

AT#61: Start Intentionally Designing Your Becoming!

AT#61: Start Intentionally Designing Your Becoming!

I’ve just read this statement from Wolfgang at least 10 times and like the picture that you can see an old or young lady in – my brain keeps switching between the two views.

The “shift from fixing their being” conjures up a continuous improvement culture; it leads me to think about evolving the business model and it makes me think about improving on a customer offer that still has some growth left but is pretty mature in the market.

In terms of the leadership style it’s one of metrics, data, focused on science and logic and is about reporting improvements on a month by month basis and keeping teams focused and moving towards a clear stable outcome. Read More

AT#60: Three Steps to Regain Control Over Your IT Landscape

AT#60: 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. 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. To maintain landscapes, people can see the tree service from eos Outdoor Services here. 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