Lifecycles Within Lifecycles

As we enter a new holiday season, Im reminded of the cyclical nature of things. New to old, start to finish, round and round. And I realize just how often we talk about lifecycles in architecture without truly understanding what our own lifecycle should focus on. Do we for example design from innovation to delivery to usage of a product? Or is it from a business objective? Do we start with business requirements? With programs or portfolios of work? Are we focused on delivering others visions or inventing visions ourselves?

[Lifecycles in the BTABoK](Architecture Lifecycle | IASA - BTABoK)

What is a lifecycle?

A lifecycle is a thing that exists from beginning to end. A product lifecycle lasts from inception to decommission. A production lifecycle is a regular way of producing products. A business lifecycle may go from order to ship. A lifecycle is often not even a thing itself, but just the process a thing goes through. I am aging each year. The world turns, and christmas shows up again and then before you know it, I am a year older. But the aging is not me. The process impacts me but does not define me. An yet these days we often identify with the lifecycles we are a part of...

We Are (Fr)Agile

I remember being introduced to iterative development. It was super simple. Instead of definining all the requirements up front, we would define some of them, build to that, test what we'd built and then do more. Keep going until we had a working product. It was a lovely idea, especially for the kind of mid-level software we were building at the time. E-commerce, shipping management, point of sail, insurance management, and the like. These adapted well to iterative development. Continuous development servers allowed us to do do dynamic builds... god I loved seeing who would wear the dunce cap (even when it was me). It was a cool project management lifecycle Then someone came around and named it... gave it religion. Gave it a belief system. Turned a lifecycle management technique for development into big A company belief system. Now we argue that Agile is Dead, and Agile Kills Architecture and well whatever keeps people listening to podcasts.

I wonder if were were to look at the number of lifecycles that make up big A agile how many we might find?

• The finance lifecycle: most people will tell you big A(ss) agile doesnt work well without changing finance. Turns out if you have to scope something up front then you have to design it up front. Oops. It is interesting that 12 weeks, 1 quarter are just enough to budget for some new features that we can sell in product lifecycles. So that part seems to work well.
• The infrastructure lifecycle: the world is filled with huge products that take decades to roll out. There are skyscrapers and highways and chunnels and new aeroplane designs. There are oil rigs and satellites. So while some products can be fast, in general the world moves relatively slowly.
• The maintenance lifecycle: A lot of the innovation of a system happens after it goes to production. A lot of headlines make us believe the people who built it are maintaining it. But in reality most of that work still goes through a different cycle.
• The customer lifecyle: We like to pretend we get an infinite shot at making customers happy, but the truth is we mostly get one. And when enough of those are bad, we get no new customers. Features and functionality dont do it. We have to understand the customers job and help them do it.
• The HR lifecycle: We dont exactly live in a keep your people for life culture anymore. 2-3 year job lenghts are the norm and very few (including the executives) actually care that much about the outcome of the company after they leave. This is a dangerous game we play. The rotating door of talent makes me concerned about the other lifecycles.

The Architect Lifecycle

Architects build things. We are creative professionals. We make cathedrals. We make solutions. We make better business outcomes in particular ways. I have never seen a group of people who so deeply care about the products they create.

Delivery of an outcome based on a business and technology strategy is 90% of architects jobs in practice. This means we touch a LOT of lifecycles. And that is why we must be so very good at navigating them. At discussing pros/cons without religious belief, even without emotion. Building beautiful things is its own reward. How we get there is part of the price we pay to do it.

The actual architecture lifecycle then is the method used by ALL of the architects in the practice to deliver value to the organization! But beware, this means all of them. You can't put business architects in one stack and solution in another and enterprise in a third. The architecture lifecycle is what change we are impacting and how we are impacting that change. Are we reviewing others work in governance? Are we down in the code like engineers? Are we in the clouds like management? How we stay connected to our value proposition is based on our answer to this!

https://iasa-global.github.io/btabok/lifecycle_planning_canvas.html

Use the lifecycle planning canvas attached to demonstrate your own architecture lifecycle and see if it matches with what you want it to be!

I will be starting a series of architecture lifecycle education sessions using common canvas techniques for different architect activities every couple of weeks.

If you are interested in learning these techniques as a whole join me in Amsterdam on Feb 12 for 5 days of architecture education (iasaglobal.org)