Blog

AT #40: Four Skills for the Successful Enterprise Architect

AT #40: Four Skills for the Successful Enterprise Architect

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

AT#39: EAM – Be a Gardener not an Architect!

AT#39: EAM – Be a Gardener not an Architect!

“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

AT#37: Stop Botching your IT-Landscape!

AT#37: Stop Botching your IT-Landscape!

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

AT#36: How to be Successful with Strategic Information Technology Landscape Planning

AT#36: How to be Successful with Strategic Information Technology Landscape Planning

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

AT#35: How to be Successful with Application Landscape Planning Part 2

AT#35: How to be Successful with Application Landscape Planning Part 2

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

AT#34: How to be Successful with Application Landscape Planning

AT#34: How to be Successful with Application Landscape Planning

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

AT#33: Why we need a new Agile Manifesto

AT#33: Why we need a new Agile Manifesto

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

Architectural Thinking Newsletter April 19

Architectural Thinking Newsletter April 19

Now, half a year after founding the Architectural Thinking Association®, it is time to communicate the current status to the growing community.

 

What have we achieved so far?

 

(i) We’ve built an interdisciplinary Leadership Team

I am very happy that we were able to build a strong, interdisciplinary ->Leadership Team. It consists of six renowned people from the fields of Business Strategy, Business Architecture, Enterprise Architecture, Enterprise Design, and Agile Solution Development and myself.

Read More

AT#31: Soft Factors of Architecture – Part 3: Communication

AT#31: Soft Factors of Architecture – Part 3: Communication

Enterprise Architecture (EA) often focuses primarily on the analytical modeling aspects and this is, of course, an important part of the work. However, practice shows that EA is much more about communication. You simply need to elicit the wisdom of business people to create your architecture maps. Enterprise Architects, and IT-people in general, however, are often not educated in communication skills like asking the right questions and listening intently. Educated at technical universities most of them have been trained to engineer highly sophisticated technical solutions but not so much in the soft skills.

The following communication skills are mandatory for any successful Enterprise Architect:

Read More