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

We have written many posts at the Architectural Thinking blog that deal with the business aspects of architecture. Business architecture is at the core of Architectural Thinking and must be connected to vision/strategy and solution development. Business architecture drives IT architecture, not vice versa. This doesn’t mean, however,  that the technology landscape of a company does not need to be governed! Technology is the basis that supports applications that support the business as shown in the meta-model of the Architectural Thinking Framework: Read More

We have written many posts at the Architectural Thinking blog that deal with more strategic topics like vision, strategy and business architecture and how to connect this to solution development. The common aim defines the direction the company shall go, based on a vision statement created by executives. After that, business architecture comes into play and make the vision more operational.

In our ->last blog post we discussed how a capability map can be used for strategic application landscape planning by assigning existing applications. Today we show a great way to model how the application landscape shall evolve over the next years. A mid-time view of 3-5 years is important because legacy renovation and introduction of new platforms take its time (this reality cannot be ignored even in the VUCA world). Read More

We have written many posts at the Architectural Thinking blog that deal with more strategic topics like vision, strategy and business architecture and how to connect this to solution development. The common aim defines the direction the company shall go, based on a vision statement created by executives. After that, business architecture comes into play and make the vision more operational. The upcoming posts show how strategic planning of the application & technology landscape can be operationalized using two simple architecture maps: application map and technology map.

Read More

The Agile Manifesto, created by seventeen guys from the field of software engineering eighteen years ago has certainly changed the way we create software solutions fundamentally and radically. The great majority of software development projects is done using agile practices like Scrum. Today, everybody knows the famous “we value X over Y” statements:

In recent years, ideas for scaling agile to a company-wide scope (eg, SAFe ©) and approaches to the “agile organization” have become increasingly popular. Nowadays everything needs to be “Agile”, Read More