I have recently been studying the implications of Agile on enterprise and technology architecture. As a part of that I was looking through traditional architects relationship to other team members (structural engineers, construction, plumbers, electricians, etc). This has always been a passion of mine as a student of professions but this time I was looking at the content of their work instead of role integration (I will have another post on that soon enough). What emerged from this has been in the back of my head for a long time in a very ambiguous sort of way.

It is very clear that the purpose of architects is fundamentally different than those of developers, engineers, project managers, etc and that projects, programs etc that have skilled architects are significantly more successful in terms of outcomes to the business (Value of Architecture). When I speak of outcomes, I am less interested in traditional measures of success such as project schedule, budget and requirements and more outcomes to new revenue, new customers, customer satisfaction, and other business value management outcomes. However, it wasn’t until I was presented with the agile motto, ’emergent architecture’, that I realized the true difference between what Iasa means when it uses the term architect, and the meaning of many others when they use the term.

When we discuss architecture, we are describing it’s Form. When others discuss architecture, they are describing it’s structure. Structure can be emergent. It is my belief that form cannot (or only rarely).



When you think of a building you love, what do you think of? It’s simplicity, complexity, beauty, usage, ability to serve its purpose while fitting into its surroundings? Form in building architecture is the final output. But it is also more than that. It is the value that output creates including the ‘negative space’ which fulfills those things. Negative space is a way of describing that things that aren’t built are as important as things that are. But it is the value that is created that interests me.

In building architecture form can be readily understood at a visceral level. Value is based on elements that most humans can ‘feel’ if not conceptualize. The difference between a good house/apartment layout and a bad one is something most adults have experienced at least once. “Who designed this place, I can’t even put a sofa in the living room!”

In technology architecture it is something a bit more esoteric. Iasa contents that form in technology architecture is the value, satisfaction and outcomes associated with a technology AFTER it is deployed and running. And this form drives and constrains structural decisions for the architect.


Now think of the same building during construction. That same beautiful and amazing building would not be very inviting to anyone but a building professional, or in my case a 10 year old boy (I grew up in construction and loved it before they were finished). Why is that? It is because until the building is completed it cannot create its intended value for the owner/customer. You likely do not want to live in a house from the beginning of construction.

The structure of the building again is a very visceral feel. The struts, the foundation, the plumbing, the machinery. For people in the building trade it is forever fascinating. In fact, I believe that this is where our notions of architecture in technology have derailed. For structure is the responsibility of both the architect AND the engineer/developer.

Structure is the set of physical and digital components, their interfaces, and the design rationales that control their evolution. It is this that most people think of when talking about architecture. But therein lies the problem we face today. Structure by itself is not valuable to an organization nor is it the soul responsibility of a single professional. Structure CAN be emergent and most often is.



A significant number of programs, projects and products are delivered by function alone. Imagine your building again. Now imagine if they had added just one room at first with no electricity, air conditioning, roof, or other elements. Then the next year they added another room and one light socket. And so forth and so on.

Function in building is roughly equivalent to requirements or user stories in technology driven business initiatives. “Lets setup a Facebook page. Social media!” “We need to be able to calculate the tax on an item in Seattle.” You get the picture. This starts to sound a lot like a truly agile initiative. Focus on the stories that make for a minimum viable product then iterate and transform and adapt. And from a development perspective it is simply heaven. I am NOT bashing agile, nor DevOps, in fact you will find that these definitions make architecture and agile significantly more powerful.

Bringing It Together

Why? Why can’t the team build function and value at the same time? For exactly the same reason that structural engineers, construction workers and building architects are all required to deliver a truly valuable output. Skills, experience, focus. Human limits. The value management (Form) of a product is a fundamentally different set of skills and experience than the construction though they overlap significantly within respective areas. In fact, it takes years to understand the nuance of the impact of technology on a business model while retaining enough technology skill to be relevant and to be able to partner effectively with a delivery team.

But why can’t the product owner understand and manage value delivery? For roughly the same reasons that traditional requirements do not describe an effective outcome in technology and business strategy. Most product owners are decidedly not technical and most delivery teams are decidedly not value management experts (argue if you will but do YOU really want to study cost benefit analysis of social media strategies, tools and techniques, or would you rather be learning Swift?). Being a truly great engineer/developer is a more than full time gig, don’t try and be super human.

What happens then when architects own the Form and Structure and the delivery team owns the Structure and Function? This is what we call healthy tension (that future article I am writing). It is the best of both worlds and allows Structure to Emerge, just NOT Architecture.