To unleash its enormous power, Enterprise Architecture (EA) must be implemented as a management instrument that is the basis for important strategic decisions. In practice, however, EA is still a mystical discipline, ruled by vague frameworks and done by a small EA group far away from executive boards. In most companies, EA has no or very limited impact on strategic business decisions. Enterprise Architecture SHOULD be a management instrument but fails in practice. Read More

The Architectural Thinking Association® celebrates its first birthday! A lot has happened in this year, and plans are getting clearer and clearer, so – let’s have a look at the results we’ve achieved so far and at our next steps:

We’ve built an interdisciplinary Leadership Team

I am happy that we were able to build an active, multidisciplinary ->Leadership Team. It consists of seven renowned people from the fields of Business Strategy, Business Architecture, Enterprise Architecture, Enterprise Design, and Agile Solution Development. In our monthly calls, we discussed our mission, the conceptual foundations of Architectural Thinking, and future steps. Read More

Business agility is at the top of the priority list of CEOs. They want to get quick and agile like a rabbit that can change direction with each jump. This kind of agility, however, can only be achieved by well-designed enterprises that are adaptive to their surroundings. Like an octopus that can change shape and color in an instant.

But how to become a sustainably adaptive enterprise that survives disrupting competitors?

Read More

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

Structure not only increases our chance to success,
it makes us more efficient at it.’ – Marshall Goldsmith

When people discuss digital transformation, they talk mostly about innovation, agility and new technologies. Companies put a tremendous amount of effort into initiatives that should make them more agile and innovative, but most of the companies I know do not manage their innovation initiatives towards a big architectural picture. The overly complex structure of dependencies between innovation- and other projects, and between new technologies and legacy-IT, are not handled with intent. Just present a fancy technology to top-level executives. If it has a low time-to-market and includes AI, chances are high that you can do it. No matter if it’s integration with legacy IT results in unnecessary complexity, ‘technical debt’ that introduces a total cost of ownership that outnumbers the business benefits by far. No matter if it is architecturally sound.

Let’s have a closer look at what ‘architecturally sound’ means, what architecture is all about and why the concept of architecture is helpful, especially in the context of innovation: Read More

The famous parable of the blind men and an elephant is a story of a group of blind men, who have never come across an elephant before and who learn and conceptualize what the elephant is like by touching it. Each blind man feels a different part of the elephant’s body, but only one part. They then describe the elephant based on their limited experience and their descriptions of the elephant are different from each other. The complete text of the poem is here.

When I read the parable I instantly found it to be very suitable to use it for companies within the digital transformation. Companies are elephants employing blind men like: Read More

Sustainability, the “ability to exist constantly” (wikipedia) is, for sure, a strength of enterprises of the old economy. Large enterprises have been around for many decades, a proof that they are running a sustainable business.

Nowadays, driven by disruptive forces, agility seams to have overtaken sustainability on the priority ranking of executive management. Boards of directors are aware that to survive in the era of startups their companies must transform in the direction of business agility i.e. to get in a state to “rapidly respond to change by adapting an initial stable configuration” (wikipedia). They invest huge amounts of money in Agile coaches believing that this is the way to improve business agility, but many times those coaches aren’t qualified.  Organizations are looking for easy solutions to becoming agile and there aren’t any.

Having a cursory high-level glance at the two poles sustainability and agility it appears as if…

• agility interferes with the calmer flow of existing sustainable business models. Boating on rough waters into the unknown sea is a risk to sustainable survival. Is agility the enemy of sustainability?
• sustainability interferes with agility – implementing changes in the enterprise design sustainably means to think holistically and harder and thus to invest more time. Is sustainability the enemy of business agility?

No to both questions!

Agility and sustainability complement each other. They interrelate like the famous Chinese yin yang symbol that describes “how seemingly opposite or contrary forces may actually be complementary, interconnected, and interdependent in the natural world, and how they may give rise to each other as they interrelate to one another”.

But what does this mean?

1. Without a sustainable continuous strategy, you cannot be agile in the medium term.

The architecture of your enterprise supports an agile business only if it has been designed for change. The building of flexible business&IT solutions that fit together to form a sound business architecture needs commonly used elements and ‘conceptual integrity’. This means that the concepts and structures of the business (capabilities, value streams, products & services, business objects, organizational structures) and IT must play together to form an agile enterprise design that maximizes simplicity, consistency, and thus business agility.

You need to go slower in the short term to become/stay fast in the long term.

2. Without business agility, you cannot sustain…

…because you cannot adapt to changing environments – the startups will take over. The strategies of yesteryear don’t provide sustainability any more.

The secret path to true business agility seems to be to solve this sustainability/agility paradox. To find the right speed for building strategic solutions. To be fast enough to survive in constantly changing times but to take enough time to build sustainable. To balance speed/agility with sustainability.

Solution for this paradox? You must become a sustainably agile enterprise

What you should do to become a sustainably agile enterprise

• Create a lean, business-oriented architectural model of the existing structure of your enterprise collaboratively (involving business & IT people)
• Set up lean governance structures to enable sustainable strategic decisions based on the solid information of this architecture model
• Realizes small innovative minimum viable products (MVP) to evaluate new business opportunities using new technologies
• Once MVPs have proven to create business value: take your time to integrate them properly with your existing business&IT structures

Previous Posts:

AT#20: Why Digital Transformation fails without Architecture

AT#15: How to make decisions in uncertain Times

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

In our last blog post, we discussed why enterprises cannot be architected but must be grown. We argued that the role of Enterprise Architects must change from purely engineering to engineering & business & social.

As an EA: establish a framework for growth. Plant the seeds. Do some weeding and fertilizing now and then. With a bit of luck, you will have a nice, healthy, growing enterprise a few years down the road. EA succeeds when enterprises are treated as complex systems that are constantly changing and adapting.

This week we want to discuss the skills required for this new kind of Enterprise Architects: Read More

“I think there are two types, the architects, and the gardeners. The architects plan everything ahead of time, like an architect building a house. They know how many rooms are going to be in the house, what kind of roof they’re going to have, where the wires are going to run, what kind of plumbing there’s going to be. They have the whole thing designed and blueprinted out before they even nail the first board up. The gardeners dig a hole, drop in a seed and water it. They kind of know what seed it is, they know if planted a fantasy seed or mystery seed or whatever. But as the plant comes up and they water it, they don’t know how many branches it’s going to have, they find out as it grows.”

Novelist R.R. Martin

Over the course of my twelve years of experience as an Enterprise Architect, I have seen EA initiatives in more than twenty large companies; only two or three of which were successful, i.e., they had a significant or even noticeable impact on the real world’s software-projects. A pattern I saw, again and again, is that the ‘planning-oriented’ top-down, engineering approaches typically employed by EAs do not work when faced with the unknowability and unpredictability of real-world bottom-up software development projects. This observation made me think that enterprises aren’t architected at all. Defining a target state for five years later? There are too many unknown influencing factors. Read More

Things happen in IT projects.  At times, some quality elements will be sacrificed in order to offset the vagaries of the project delivery scene.  A solution that works of course.  But as discussed in a previous article, a working solution brings no comfort regarding its quality, since almost anything can be done in the virtual dimensions of software and computers. And when issues arise to put pressure on IT teams, a suboptimal alternative will be presented as a fix, a patch, a temporary solution, or as the most wickedly named: the tactical solution. In circles of experienced IT managers and practitioners, the ‘tactical solution’ sits somewhere between fairy tale and sham.

The word ‘tactical solution’ suggests to the non-IT stakeholder that the chosen tactic is a step sideways, and that once the applicable steps are taken, the product should attain the desired state, which is often labeled as the strategic or target solution. Because the tactical solution works (since anything in IT can be made to work), it could be viewed as a small step in the right direction.

After this dodged solution is implemented, we simply need to perform a few extra steps to reach the strategic state, right?

 

Not really.

Read More