The First Bullet from "Strategy to Execution"

I have been reading Whynde Kuhn's Strategy to Reality and it is an absolute page-turner for everyone interested in big-picture thinking. A few words I read in the first chapter of the book struck me so hard that this article was inspired. I am going to quote her words verbatim in this article but I would ask that the reader considers the most other aspects of the article my reflections on her thoughts.

In my mind I have brought her thoughts about strategy and business architecture into my evolving world of enterprise architecture. I am also using her thoughts to support a position I have held for quite a while on the relationships between architecting and implementing, strategizing and executing. Whynde Kuehn says,

"The strategy execution framework is agnostic to the development methodology. It makes no differences whether the organization embraces waterfall or agile approaches." - Whynde Kuehn

The moment I saw "development methodology", I recalled the interesting conversations I have had or witnessed regarding the balance between agile and waterfall particularly when colleagues perceive architecting as excessive pre-implementation planning.

Waterfall and Agile

Debates about legacy and emerging project management methodologies have been around for years. Many thought leaders have also embarked on the largely academic excercise of comparing agile with waterfall. I say "largely academic" because in my experience no organization embraces any framework in its entirety. In fact, some even use frameworks as a mask for doing what they have always wanted to do anyway. Do let me know if you have a different experience regarding framework adoption.

Those who have explore waterfall vs. agile highlight the following thoughts in one form or another:

1. Waterfall requires complete upfront planning while agile embraces changes to requirements along the way. Agile makes room for accomodating changes to requirements by executing large projects in small chunks.
2. Waterfall lays emphasis on structure, documentation and formality while agile is more concerned about outcomes. Agile gives little room for governance and a tendency to allow "fast" failure and recovery during implementation.
3. Many organizations which are interested in speed to market welcome agile especially in the world of software development. Agile was originally designed for software projects; some projects may not benefit from agile due to the potential for technical debt arising from low upfront planning.

On a side note it is ingenious how well documented Agiel Software Development is and the assumption that those engaged in face-to-face conversations will be around in the same company for considerable lengths of time. Debate for another day.

Project by Project

Interestingly, those who have taken on this subject often express their opinions on selecting an appropriate methodology for each project. This implies neither methodology is a one size fits all. This means we have to know something about the project before we decide. On another side note, I am not sure whether the naming of these two methodologies was designed to give the latter a better appeal in our fastfood-oriented generation. Agile certainly has appeal in its promise of speed and freedom from what may be perceived as obscene levels of scrutiny (often labelled analysis paralysis).

In my experience, many professionals especially technical professionals tend to defend their lack of discipline by tilting their head slightly over the video call and haughtily emphasing that we have to be agile (did you just hear Elizabeth Holmes' deep voice?). Of course I am exageratting but you know what I mean. Agile does not simply mean doing things faster in my opinion. We still have to know what the epic is, we still have to manage a backlog and we still have to have guardrails.

Are We Gradually Re-Accepting Forethought?

In fact, Dean Leffingwell and Drew Jemilo came along 10 years after the agile manifesto was published in February 2001 to declare that agile is NOT SAFE for larger enterprises (that was a joke). They combined concepts from agile software development, lean product development, and systems thinking to create a framework labelled SAFe - Scaled Agile Framework for Enterprises.

Samuel Holcman often argues that the accepted margin of error we find in information technology is not present in other established professions. Imagine forgetting the elevator while erecting a 100-storey building. In Sam's respected opinion, even frequent software updates are an indicator that something is lacking in the way we architect solutions in the information technology profession. What do you think?

Feature-Driven Development proposes starting with big picture thinking first and then planning by features. I particulary like this one because what it is saying in essense is that we have to have a fair idea of the big picture (the WHAT) in my world before breaking down the project into implementation steps. It is almost a middle ground between waterfall and Agile software development.

FDD describes five basic steps that make up a management project life cycle.

• Develop Overall Model
• Build the Feature List
• Plan by Feature
• Design by Feature
• Build by Feature

In my world, enterprise architecture, it makes sense to me to see the big picture first. Architecture is about conceptualizing. When introduced as part of an ongoing project, it appears to be a fruitless theoretical excercise, a showstopper! That is when the techies raise the "We Have to Be Agile" placards. When we do architecture in a hurried fashion just for the sake of it, we do not get the value and end up reinforcing the thinking that this is just time-consuming bureaucracy.

It Only Makes Sense - Forethought and Broad Thought

Quite a few expressions are used to identify the concept of big picture, long-term thinking. Whatever we choose to call it, it is only logical that before we embark on something serious, we think about it deeply, and we think about the consequences of each choice we make on future outcomes. This is what architecture is about - brainstorming options, evaluation relationships, concerns, considerations, constraints etc. Systems Thinking formalizes these concepts with sophisticated methods and tools such as causal loop diagrams and management flight simulators.

Elements of strategy also try to address big picture and long term thinking. Organizations try to take up a position that gives them the greatest competive advantage without going to deep into how that will be achieved. The position they take up then drives the other more tactical and hopefully operational choices they make. Based on Whynde Kuehn 's persepctive, business architecture is a bridge that enables execution of strategy in an iterative fashion.

Maybe I am Still "Old School", but this is Architecture!

Architecting is not the same as documentation but architecture certainly involves quite a bit of documention. Some argue that as long as we are writing things down we are documenting! Besides, AI can transcribe all our conversation. The question is are we able to reuse the documents for the purpose we desire and designed it for. I tend to tilt towards what might be perceived as excessive, structured documentation for a few reasons.

I Write - It's a Personal "Thingy"

It is personal. I am a writer so it comes naturally. I also come from a family with a variety of artistic talents so I do enjoy creating diagrams even when no one looks at them after they are created. Popularity is not always the proof of value. Artefacts must be created and curated to such a degree of excellence that they are readily available and valuable the day they are needed.

The Text Represents Our Collective Thoughts

I consider writing a reflection of thinking. The process of building architecture is more important than the output. The more we are able to create artefacts that everyone can see, the more shared understadning we achieve. I consider excessive documentation as being thorough not being superfluous.

This is an Organization

I am always conscious of the transient nature of employment contracts. In one organization I worked for, we more than once had to discard a custom application because the lead developer was no longer in the company. You may consider that an example of "fail fast" but it is bad for both the organization and the developer from the perspective of long term thinking.

We Can Still Be "Agile" in Architecture

If I am engaged by a new organization requiring a formal architecture practice, I would like focus on at least four areas in the first year.

1. Architecture Blueprint - Can we understand our overall big picture and decide where we go from here over the long term?
2. Architecture Artefacts - Can we develop a consistent way to represent architecture components so stakeholders can interprete the artefacts?
3. Architecture Repository - Can we centralize and socialize our architecture artefacts and reference/reuse them when we need to?
4. Architecture Cadence - Can we adopt a formal system for governing architecture and ensuring the voices of tech and non-tech stakeholders are consistently catered for in architecting each initiative?

Here I have not mentioned any framework or tool. I have simply attempted to address the philosophy - we mush have a collective understanding of what we are about to build consistently. Whether we are building an enterprise or a solution, we have to get this understanding and work with it. And like Khuen shared in her book, whether we choosing to implement using waterfall or agile methodologies, such clarity is still required.

We do not have to complete architecture elements of all solutions before we begin. That might be impractical in many contexts. But we have to know where we stopped and pick up from there. In additon, we have to know where we are going even if it is at a low level of granularity.

Practically Architecting Foundations

Virtualization, containerisation and cloud computing are three well-known examples of significant levels of forethought done prior to becoming agile.

Containers allow us to implement capabilities a very low levels of granularity. Each function can be implemented as a microservice and deployed in a pod - a collection of containers. The concept of containerization increases availability significationly but importantly ensures that if we need to change functionality, because we can do this on specific microservices and deploy are new versions of container images.

In order for all this fancy stuff to be possible, we must first first build the foundations - a cluster based on an orchestration engine designed to ensure availability, scalability and maintainability of containers. We must have mechanisms for API calls, data stores and appropriate sizing of containers. All these are foundations carefully thought through for us to implement our agile software developement on.

Virtualization and Cloud tell a simlar story. Our ability to reuse images, templates and patterns is based on detailed design of these platforms to align with principles of high availability, simplicity, security and more. Someone else has done the work in this case. May sound like the quick win some organizations ebrace - outsource the thinking. Well, as much as a vendor might be an expert in their product, the internal IT team must decide how the new product fits into the existing architure.

Conclusion

Let me end my musings by recalling Whynde Kuehn 's thoughts again,

"It is important to get the business architecture baseline as right as possible up front.... However, once the baseline is in place, keep going. Keep capturing content for all other domains just enough, just in time"

I could easily replace "business" with "enterprise" or "solution" as the adjective for "architecture" in the statement. I could also be bold enough to replace "domains" with "components". This brings it close to my space. For each initiative, start with capturing as much as we know and curate it. Update the centralized architeture as more information becomes available. It is a balance between sufficient forethought and not being a blocker.

This is not the end of this conversation. So, what do you think?