Always inspiring, a seminar by Chris Potts. So I was keen on joining this evening’s EA Café about linking enterprise architecture to enterprise investment. If you haven’t read his books or participated in one of his workshops, I strongly encourage you to do so. Here are some things and questions that stuck with me today.

Enterprise architecture, on its own delivers no value. As illustrated in my blog on outside-in architecture, the final goal of enterprise architecture is to design structures that create business value.

Therefore enterprise architects operate on the link between strategy and execution, connecting the investment chain with the operational value chain. To be able to improve the structure of enterprises, enterprise architects have to collaborate with business executives, investment portfolio managers, project teams and operational people as illustrated in the following picture:

In this blog I want to share my insights on how I see these collaborations happening in practice. Be aware that I will explain the collaborations top down, which in practice will often not be the case. In my experience, I mostly jump in at the project level to create early value and continue my journey from there on.

As an enterprise architect, I ask myself continuously the question how I can contribute to the creation of business value for the enterprise. How can we design or improve structures that enable the enterprise to create more value?

The basic model

If we look at an enterprise from a very high level, the basic model of an enterprise is to turn the money of investors in business value for customers, in collaboration with partners in the supply chain.

If we want to take the word ‘enterprise’ in our job titles seriously, I believe we should change our mental model from an inside-out oriented perspective to an outside-in oriented perspective. How can we connect the investment value chain with the operational value chain to create more value for the customer?

In this post I will summarize some of the main principles of Jez Humble and David Farley’s great book on Continuous Delivery and share my experiences of applying them on software projects I’ve been involved in. First, I’d like to share a story to give this discussion some context.

Meet Joe

Joe is a software developer. It’s a regular Friday afternoon, 15 PM. Before heading home, Joe has to start this thing called a “weekly build”. Joe makes sure everyone on the team has checked in their changes to the source control system.

Joe starts the fully-automated build at the click of a button. The current build process takes some time, so he grabs a coffee. Five minutes later Joe returns to his computer, only to be shocked by what his monitor is displaying:

build failed.